Skip to main content

EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol
draft-ietf-ace-coap-est-18

Revision differences

Document history

Date Rev. By Action
2022-03-24
18 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-02-18
18 (System) RFC Editor state changed to AUTH48 from AUTH48-DONE
2021-08-30
18 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-08-12
18 (System) RFC Editor state changed to AUTH48
2021-07-16
18 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-06-28
18 (System) RFC Editor state changed to REF from EDIT
2021-06-22
18 (System) RFC Editor state changed to EDIT from MISSREF
2021-05-03
18 (System) RFC Editor state changed to MISSREF from EDIT
2021-05-03
18 (System) RFC Editor state changed to EDIT from MISSREF
2020-01-23
18 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-01-23
18 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-01-23
18 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-01-21
18 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-01-16
18 (System) RFC Editor state changed to MISSREF
2020-01-16
18 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-01-16
18 (System) Announcement was received by RFC Editor
2020-01-16
18 (System) IANA Action state changed to In Progress
2020-01-16
18 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-01-16
18 Amy Vezza IESG has approved the document
2020-01-16
18 Amy Vezza Closed "Approve" ballot
2020-01-16
18 Amy Vezza Ballot approval text was generated
2020-01-15
18 Benjamin Kaduk IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-01-06
18 Adam Roach [Ballot comment]
Thanks for addressing my discuss and comments!
2020-01-06
18 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2020-01-06
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-01-06
18 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-01-06
18 Panos Kampanakis New version available: draft-ietf-ace-coap-est-18.txt
2020-01-06
18 (System) New version approved
2020-01-06
18 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2020-01-06
18 Panos Kampanakis Uploaded new revision
2020-01-06
17 Alexey Melnikov
[Ballot comment]
Thank you for this well written document. And thank you for addressing my points in github.

A remaining comment (which might or might …
[Ballot comment]
Thank you for this well written document. And thank you for addressing my points in github.

A remaining comment (which might or might not have been resolved):

5.1.  Discovery and URIs

  Clients and servers MUST support the short resource EST-coaps URIs.

Just to clarify: the original EST URIs are prohibited in COAP-EST?
2020-01-06
17 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss
2019-12-29
17 Magnus Westerlund [Ballot comment]
Thanks for resolving my Discuss in the upcoming version.
2019-12-29
17 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2019-12-19
17 Amy Vezza IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2019-12-19
17 Magnus Westerlund
[Ballot discuss]
Section 5.6:

The EST-coaps client MUST support
  Block1 only if it sends EST-coaps requests with an IP packet size
  that exceeds …
[Ballot discuss]
Section 5.6:

The EST-coaps client MUST support
  Block1 only if it sends EST-coaps requests with an IP packet size
  that exceeds the Path MTU.

I think the requirement for when Block1 is required to be supported in the above sentence is unclear. Is the intention to say: An EST-coaps MUST support block1 to be capable to send requests that would otherwise result in the reliance on IP level fragmentation?
2019-12-19
17 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2019-12-18
17 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-12-18
17 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-12-18
17 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-12-18
17 Alexey Melnikov
[Ballot discuss]
Thank you for this well written document. I have a couple of small DISCUSS points and a few minor comments/questions that I would …
[Ballot discuss]
Thank you for this well written document. I have a couple of small DISCUSS points and a few minor comments/questions that I would like to discuss.

DISCUSS:

5.4.  Message Bindings

  o  The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-
      Format, Block1, Block2, and Accept.  These CoAP Options are used
      to communicate the HTTP fields specified in the EST REST messages.
      The Uri-host and Uri-Port Options can be omitted from the COAP
      message sent on the wire.

The statement above

      When omitted, they are logically
      assumed to be the transport protocol destination address and port
      respectively.  Explicit Uri-Host and Uri-Port Options are
      typically used when an endpoint hosts multiple virtual servers and
      uses the Options to route the requests accordingly.

and the last quoted statement: How can the sender know whether or not it is Ok to omit Uri-Host/Uri-Port?


7.  Parameters

  It is recommended, based on experiments,
  to follow the default CoAP configuration parameters ([RFC7252]).
  However, depending on the implementation scenario, retransmissions
  and timeouts can also occur on other networking layers, governed by
  other configuration parameters.  When a change in a server parameter
  has taken place, the parameter values in the communicating endpoints
  MUST be adjusted as necessary.

The last sentence: use of MUST with passive voice is really unhelpful here.
Adjusted by whom? How can this MUST be satisfied?
2019-12-18
17 Alexey Melnikov
[Ballot comment]
Comment:

5.1.  Discovery and URIs

  Clients and servers MUST support the short resource EST-coaps URIs.

Just to clarify: the original EST URIs …
[Ballot comment]
Comment:

5.1.  Discovery and URIs

  Clients and servers MUST support the short resource EST-coaps URIs.

Just to clarify: the original EST URIs are prohibited in COAP-EST?

In 5.8:

  In the case where the asymmetric encryption key is suitable for
  transport key operations the generated private key is encrypted with
  a symmetric key which is encrypted by the client-defined (in the CSR)

I would break up this sentence into 2 to make it clearer, as I initially read this as 2 encryption operations applying to the generated private key itself.
So I suggest something like:

In the case where the asymmetric encryption key is suitable for
transport key operations the generated private key is encrypted with
a symmetric key. The symmetric key itself is encrypted by the client-defined (in the CSR)

  asymmetric public key and is carried in an encryptedKey attribute in
  a KeyTransRecipientInfo structure.

  Finally, if the asymmetric
  encryption key is suitable for key agreement, the generated private
  key is encrypted with a symmetric key which is encrypted by the
  client defined (in the CSR) asymmetric public key and is carried in
  an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo.

As above.
2019-12-18
17 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov
2019-12-17
17 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-12-17
17 Adam Roach
[Ballot discuss]

Thanks for the work that the authors and working group put into this document.
I have one DISCUSS-level comment that should be very …
[Ballot discuss]

Thanks for the work that the authors and working group put into this document.
I have one DISCUSS-level comment that should be very easy to resolve, and
a small number of editorial nits.

---------------------------------------------------------------------------

§9:

Since this specification is adding new endpoints under /.well-known/est,
it needs to update the "Well-Known URIs" registry so that the entry for
"est" indicates this document (in addition to RFC 7030).
2019-12-17
17 Adam Roach
[Ballot comment]

§5.3:

>  The Content-Format (HTTP Media-Type equivalent) of the CoAP message

HTTP doesn't have a "Media-Type" field. Presumably this intends to
say "Content-Type"? …
[Ballot comment]

§5.3:

>  The Content-Format (HTTP Media-Type equivalent) of the CoAP message

HTTP doesn't have a "Media-Type" field. Presumably this intends to
say "Content-Type"?

---------------------------------------------------------------------------

§5.3:

>  Media-Types specified in the HTTP Content-Type header (Section 3.2.2

Nit "...header field..."

---------------------------------------------------------------------------

§5.5:

>  HTTP response code 202 with a Retry-After header in [RFC7030] has no

Nit "...header field..."
2019-12-17
17 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2019-12-17
17 Alissa Cooper
[Ballot comment]
Section 10.1:

"It is also RECOMMENDED that the Implicit Trust Anchor database used
  for EST server authentication is carefully managed to reduce …
[Ballot comment]
Section 10.1:

"It is also RECOMMENDED that the Implicit Trust Anchor database used
  for EST server authentication is carefully managed to reduce the
  chance of a third-party CA with poor certification practices
  jeopardizing authentication."

This strikes me as a slightly odd use of normative language (what are the exception cases when the trust anchor database should not be carefully managed?).
2019-12-17
17 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-12-17
17 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-12-16
17 Barry Leiba
[Ballot comment]
Thanks for this — a useful document.  I have a bunch of comments, but they’re all editorial.  Please consider them, but there’s not …
[Ballot comment]
Thanks for this — a useful document.  I have a bunch of comments, but they’re all editorial.  Please consider them, but there’s not a need to give a detailed reply.

-- Section 4 --

      In that case, the
      server MAY want to authenticate a client certificate against its
      trust store although the certificate is expired (Section 10).

Total nit: Why "want to"?  Why not "server MAY authenticate"?

  As described in Section 2.1 of [RFC5272] proof-of-identity refers to
  a value that can be used to prove that the private key corresponding
  to the certified public key is in the possession of and can be used
  by an end-entity or client.

I find the passive voice to be quite awkward here, and suggest making it active:

NEW
  As described in Section 2.1 of [RFC5272], proof-of-identity refers
  to a value that can be used to prove that an end-entity or client is
  in possession of and can use the private key corresponding to the
  certified public key.
END

  the event of handshake message fragmentation, the Hash of the
  handshake messages used in the MAC calculation of the Finished
  message must be computed as if each handshake message had been sent
  as a single fragment (Section 4.2.6 of [RFC6347]).

I know this wording is directly from 6347, but I think it's unclear and would like to suggest an alternative.  The "as a single fragment" part is odd, because I think what it's really saying is that it's computed as if it had not been fragmented.  My suggestion is to change it thus (and similarly for the next paragraph after):

NEW
  the event of handshake message fragmentation, the Hash of the
  handshake messages used in the MAC calculation of the Finished
  message must be computed on each reassembled message, as if
  each handshake message had not been fragmented (Section 4.2.6
  of [RFC6347]).
END

If that's not correct, please take that as further evidence that it's unclear, and adjust accordingly.

  To alleviate this
  situation, an EST-coaps DTLS connection MAY remain open for
  sequential EST transactions which was not the case with [RFC7030].
  For example, an EST csrattrs request that is followed by a
  simpleenroll request can use the same authenticated DTLS connection.

Two total nits:
a. Comma before "which", please.
b. The "for example" needs some rewording to make it work:
NEW
  For example, if an EST csrattrs request is followed by a
  simpleenroll request, both can use the same authenticated
  DTLS connection.
END

-- Section 5.1 --

  EST-coaps is targeted for low-resource networks with small packets.
  Two types of installations are possible (1) rigid ones where the
  address and the supported functions of the EST server(s) are known,
  and (2) flexible one where the EST server and it supported functions
  need to be discovered.

This needs a colon (:) after "possible", a comma after "rigid ones", "a" before "flexible one", another comma after "flexible one", and make it "its supported".

-- Section 5.5 --

  Similarly, 2.04

  is used in successfull response to EST-coaps POST requests (/sen,
  /sren, /skg, /skc).

There's odd spacing here; please fix it.  And "successful" is misspelled.

-- Section 5.7 --

  If the server is very slow (i.e., minutes) in providing the response
  (i.e., when a manual intervention is needed),

I think you mean "e.g." for both of those, evidence for my general aversion to using Latin abbreviations that many people don't fully understand.  It also feels odd to have the two examples separated in this way.  I suggest this:

NEW
  If the server is very slow in providing the response (for example,
  manual intervention is required and it could take minutes  for it
  to respond),
END

  it SHOULD respond with
  an ACK containing response code 5.03 (Service unavailable) and a Max-
  Age Option to indicate the time the client SHOULD wait to request the
  content later.

Perhaps, "to indicate the time the client SHOULD wait before sending another request to obtain the content." ?

  After a delay of Max-Age, the client SHOULD resend
  the identical CSR to the server.  As long as the server responds with
  response code 5.03 (Service Unavailable) with a Max-Age Option, the
  client SHOULD keep resending the enrollment request until the server
  responds with the certificate or the client abandons the request for
  other reasons.

That last sentence reads very strangely to me.  It SHOULD keep resending the request until it decides to stop?  What does that actually mean?

Maybe what you're really trying to say is something like this?:

NEW
  As long as the server continues responding with
  response code 5.03 (Service Unavailable) with a Max-Age Option, the
  client will continue to delay for Max-Age and then resend the
  enrollment request until the server responds with the certificate or
  the client abandons the request for policy or other reasons.
END

-- Section 5.8 --

  In scenarios where it is desirable that the server generates the
  private key, server-side key generation is available.

This seems like a content-free sentence.  Maybe this?:

NEW
  Private keys can be generated on the server.  Scenarios where
  that makes sense include those where it is considered more
  secure...
END

  Of course, that does not eliminate the
  need for proper random numbers in various protocols like (D)TLS
  (Section 10.1).

May I suggest this?:

NEW
  As always, it is necessary to use proper random numbers in
  various protocols such as (D)TLS (Section 10.1).
END

  server or proxy to generate the private key and the certificate which
  are transferred back to the client

Needs a comma before "which".

  or the asymmetric keypair establishment method is out of scope of the
  specification.

"of this specification".

  [I-D.ietf-core-multipart-ct] containing a CBOR array with four items

  (Section 5.3)

  .  The two representations

More odd spacing.

  Dependent on the request, the
  private key can be in unprotected PKCS#8 [RFC5958] format

"Depending upon the request"

  In
  the case where the asymmetric encryption key is suitable for
  transport key operations the generated private key is encrypted with
  a symmetric key which is encrypted by the client-defined (in the CSR)
  asymmetric public key and is carried in an encryptedKey attribute in
  a KeyTransRecipientInfo structure.

Long sentence that needs punctuation: comma after "operations", comma before "which", comma before "and".  Also, I would move "(in the CSR)" a few words later, after "public key".

-- Section 7 --

  It is recommended, based on experiments,

  to follow the default CoAP configuration parameters ([RFC7252]).

Odd spacing, again.  But "it is recommended to follow" is also odd English.  I suggest making this active, rather than passive, thus:

NEW
  Implementations should follow the default CoAP configuration
  parameters ([RFC7252]).
END

I don't think the "based on experiments" bit adds anything, but if you want to keep it you can prepend "Experiments have shown that" to my suggestion.

-- Section 9.1 --
Don't you want to remove the "TBD" on "TBD287" here?  Wasn't the "TBD" just a flag to remind people that it hadn't been formally allocated yet?

— Section 10.1 —

  It is important to note that sources contributing to the randomness
  pool used to generate random numbers on laptops or desktop PCs are
  not available on many constrained devices, such as mouse movement,
  timing of keystrokes, or air turbulence on the movement of hard drive
  heads, as pointed out in [PsQs].

The sentence order is wrong here.  For example, mouse movement is not a constrained device.  The correct order is more like this:

NEW
  It is important to note that, as pointed out in [PsQs], sources
  contributing to the randomness pool used to generate random
  numbers on laptops or desktop PCs, such as mouse movement,
  timing of keystrokes, or air turbulence on the movement of hard
  drive heads, are not available on many constrained devices.
END
2019-12-16
17 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-12-16
17 Roman Danyliw
[Ballot comment]
* Section 4.  Per “the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other”, I …
[Ballot comment]
* Section 4.  Per “the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other”, I think the text means that some EST messages are more likely to occur one after another.  It would be worth being clearer what these would be.

* Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does Table 1 imply that when using EST-coaps the “longer names” from RFC7030 wouldn’t be valid?

* Section 5.2  Per “The latter ones are deemed to expensive …”, was difficult to parse as the sentence prior has three things (instead of two).  Is this sentence referring to the “not specified functions” only?

* Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite this metric, please do.

* Section 5.8.  Per “In summary, the symmetrically encrypted key is included in the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in a server-side key generation scenario, where is the client getting the key to decrypt the server computed key material?  Should the DecryptKeyIdentifier/ AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections 4.4.1.1/4.4.1.2 of RFC7030?

* Section 10.1.  Per “When server-side key generation is used, the constrained device depends on the server to generate the private key randomly, but it still needs locally generated random numbers for use in security protocols, as explained in Section 12 of [RFC7925].”, is the “security protocols” referenced here anything beyond DTLS?

* Section 10.1.  Per “In such occasions, checking the certificate revocation status or authorizing the client using another method is important for the server to ensure that the client is to be trusted.”

-- does this text suggest that expired+revoked certificates should not be used? 

-- to word-smith:
s/for the server to ensure that the client is to be trusted/for the server to raise its confidence that the client can be trusted/

* Section 10.1.  Per “More information about recommendations of TLS and DTLS are included in  [BCP195]”, thanks for referencing BCP195.  Could you please clarify with normative language if these recommendations SHOULD/MUST be followed?

* Editorial
- Section 4.  Per “Authenticating and negotiating DTLS keys requires resources on low- end endpoints and consumes valuable bandwidth”, I’m not sure this sentence is needed.  Technically, “authenticating and negotiating DTLS keys requires resources” on any endpoint.

- Section 4. 
OLD: Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time,
NEW: Given that after a successful enrollment, it is more likely that a new EST transaction will not take place for a significant amount of time,

- Section 5.5. Typo.  s/successfull/successful/

- Section 5.8.  s/Such scenarios could be when it is …/Such scenarios apply when it is …/

- Section 5.8.  s/ client, or when the resources/client, when the resources/

- Section 5.8. s/Then the private key/The private key/
2019-12-16
17 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-12-15
17 Yaron Sheffer Request for Telechat review by SECDIR Completed: Ready. Reviewer: Yaron Sheffer. Sent review to list.
2019-12-12
17 Tero Kivinen Request for Telechat review by SECDIR is assigned to Yaron Sheffer
2019-12-12
17 Tero Kivinen Request for Telechat review by SECDIR is assigned to Yaron Sheffer
2019-12-12
17 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-12-10
17 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-12-06
17 Amy Vezza Placed on agenda for telechat - 2019-12-19
2019-12-05
17 Benjamin Kaduk IESG state changed to IESG Evaluation::AD Followup from Waiting for Writeup::AD Followup
2019-12-05
17 Benjamin Kaduk Ballot has been issued
2019-12-05
17 Benjamin Kaduk [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk
2019-12-05
17 Benjamin Kaduk Created "Approve" ballot
2019-12-05
17 Benjamin Kaduk Ballot writeup was changed
2019-12-05
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-12-05
17 Panos Kampanakis New version available: draft-ietf-ace-coap-est-17.txt
2019-12-05
17 (System) New version approved
2019-12-05
17 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-12-05
17 Panos Kampanakis Uploaded new revision
2019-11-12
16 Benjamin Kaduk IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2019-10-22
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-10-22
16 Panos Kampanakis New version available: draft-ietf-ace-coap-est-16.txt
2019-10-22
16 (System) New version approved
2019-10-22
16 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-10-22
16 Panos Kampanakis Uploaded new revision
2019-10-22
15 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2019-10-22
15 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-10-18
15 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Nagendra Kumar was marked no-response
2019-10-18
15 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-10-17
15 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2019-10-17
15 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-10-17
15 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ace-coap-est-15. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ace-coap-est-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

In Section 9.1 of the current draft, there are references to [I-D.ietf-lamps-rfc5751bis] as references for some of the CoAP Content-Formats. However, IANA understands that these should be changed to [RFC8551].

First, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

the following temporary registrations will be made permanent and have their Internet-Draft references changed to [ RFC-to-be ]:

HTTP Media Type: application/pkcs7-mime; smime-type=server-generated-key
ID: 280
Reference: [RFC8551][RFC7030][ RFC-to-be ]

HTTP Media Type: application/pkcs7-mime; smime-type=certs-only
ID: 281
Reference: [RFC8551][ RFC-to-be ]

HTTP Media Type: application/pkcs8
ID: 284
Reference: [RFC8551][RFC5958][ RFC-to-be ]

HTTP Media Type: application/csrattrs
ID: 285
Reference: [RFC7030][ RFC-to-be ]

HTTP Media Type: application/pkcs10
ID: 286
Reference: [RFC8551][RFC5967][ RFC-to-be ]

IANA Question --> What is the status of the CoAP Content Formats that have IDs 282 and 283?

Second, also in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single, new registration will be made as follows:

HTTP Media-Type: application/pkix-cert
Encoding:
ID: [ TBD-at-Registration ]
Reference: [RFC2585][ RFC-to-be ]

IANA notes that the authors suggest a value of 287 for this registration.

Third, in the Resource Type (rt=) Link Target Attribute Values registry also on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

six, new registrations will be made as follows:

Value: ace.est.crts
Description: This resource depicts the support of EST get cacerts
Reference: [ RFC-to-be ]

Value: ace.est.sen
Description: This resource depicts the support of EST simple enroll
Reference: [ RFC-to-be ]

Value: ace.est.sren
Description: This resource depicts the support of EST simple reenroll
Reference: [ RFC-to-be ]

Value: ace.est.att
Description: This resource depicts the support of EST get CSR attributes
Reference: [ RFC-to-be ]

Value: ace.est.skg
Description: This resource depicts the support of EST server-side key generation with the returned certificate in a PKCS#7 container
Reference: [ RFC-to-be ]

Value: ace.est.skc
Description: This resource depicts the support of EST server-side key generation with the returned certificate in application/pkix-cert format
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-10-15
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Kumar
2019-10-15
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Kumar
2019-10-13
15 Yaron Sheffer Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer. Sent review to list.
2019-10-10
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2019-10-10
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2019-10-05
15 David Schinazi Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: David Schinazi. Sent review to list.
2019-10-04
15 Jean Mahoney Request for Last Call review by GENART is assigned to David Schinazi
2019-10-04
15 Jean Mahoney Request for Last Call review by GENART is assigned to David Schinazi
2019-10-04
15 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-10-04
15 Amy Vezza
The following Last Call announcement was sent out (ends 2019-10-18):

From: The IESG
To: IETF-Announce
CC: ace-chairs@ietf.org, ietf@augustcellars.com, Jim Schaad , kaduk@mit.edu, …
The following Last Call announcement was sent out (ends 2019-10-18):

From: The IESG
To: IETF-Announce
CC: ace-chairs@ietf.org, ietf@augustcellars.com, Jim Schaad , kaduk@mit.edu, ace@ietf.org, draft-ietf-ace-coap-est@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (EST over secure CoAP (EST-coaps)) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: - 'EST
over secure CoAP (EST-coaps)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Enrollment over Secure Transport (EST) is used as a certificate
  provisioning protocol over HTTPS.  Low-resource devices often use the
  lightweight Constrained Application Protocol (CoAP) for message
  exchanges.  This document defines how to transport EST payloads over
  secure CoAP (EST-coaps), which allows constrained devices to use
  existing EST functionality for provisioning certificates.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-10-04
15 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-10-04
15 Amy Vezza Last call announcement was changed
2019-10-03
15 Benjamin Kaduk Last call was requested
2019-10-03
15 Benjamin Kaduk Last call announcement was generated
2019-10-03
15 Benjamin Kaduk Ballot approval text was generated
2019-10-03
15 Benjamin Kaduk Ballot writeup was generated
2019-10-03
15 Benjamin Kaduk IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-10-01
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-10-01
15 Panos Kampanakis New version available: draft-ietf-ace-coap-est-15.txt
2019-10-01
15 (System) New version approved
2019-10-01
15 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-10-01
15 Panos Kampanakis Uploaded new revision
2019-09-23
14 Benjamin Kaduk IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2019-09-20
14 Panos Kampanakis New version available: draft-ietf-ace-coap-est-14.txt
2019-09-20
14 (System) New version approved
2019-09-20
14 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-09-20
14 Panos Kampanakis Uploaded new revision
2019-09-10
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-09-10
13 Peter Van der Stok New version available: draft-ietf-ace-coap-est-13.txt
2019-09-10
13 (System) New version approved
2019-09-10
13 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-09-10
13 Peter Van der Stok Uploaded new revision
2019-08-28
12 Benjamin Kaduk IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-08-26
12 Benjamin Kaduk IESG state changed to AD Evaluation from Publication Requested
2019-06-05
12 Panos Kampanakis New version available: draft-ietf-ace-coap-est-12.txt
2019-06-05
12 (System) New version approved
2019-06-05
12 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-06-05
12 Panos Kampanakis Uploaded new revision
2019-05-17
11 Panos Kampanakis New version available: draft-ietf-ace-coap-est-11.txt
2019-05-17
11 (System) New version approved
2019-05-17
11 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-05-17
11 Panos Kampanakis Uploaded new revision
2019-05-07
10 Jim Schaad
(1) This is requested to be a Proposed Standard.  This is correctly indicated in the document.

(2) The IESG approval announcement includes a Document Announcement …
(1) This is requested to be a Proposed Standard.  This is correctly indicated in the document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Enrollment over Secure Transport [RFC 7030] provides a REST style
  interface for doing X.509 certificate enrollment as well as other
  operations to support the enrollments.  This document provides a
  set of procedures to run this REST API using DTLS and CoAP rather
  than TLS and HTTP.

Working Group Summary

  Following adoption of the document progress in the WG was
  smooth.  The major issues in terms of formating and structure
  were worked out prior to WG adoption.

Document Quality

  The document has been reviewed and is directly build on
  RFC 7030.  Prior to the document going into last call three
  different groups of implementers got together and had a
  series of virtual inter-op events.  These lead to several changes
  and clarifications in the document as problems were identified. 

Personnel

  Jim Schaad acted as the Document Shepherd and Benjamin Kaduk was
  the Responsible Area Director.

(3) I verified the following:  All of the last call comments were addressed
in some manner, all of the necessary IANA considerations are present, none
of the examples appears to be incorrect from a cursory examination.

(4) I am happy with the review that the document has gotten.

(5) In my opinion the document does not need any broader review.

(6) The following item is a potential concern:

*  The document is using tls-unique for the purpose of channel binding.
I know that there were discussions in the TLS WG about using this or
switching to something else.  I cannot see that they ended up concluding
anything.

The authors have suggested that the correct way to deal with this issue
would be to create an update to RFC 7030, the base EST draft, to start using
the tls-exporter mechanism.

(7)  All authors have confirmed that all appropritae IPR disclosures have been filed.

** van der Stok ** YES - 4/29/19
** Kampanakis ** YES - 5/7/19
** Richardson ** YES - 4/29/19
** Raza ** YES - 4/29/19

(8) There have been no IPR disclosures on this document. 

(9) A reasonable percentage of the active members of the working group
have reviewed the document.  The majority of the reviews were from about
six people.

(10)  There have been no issues with the document.  No future problems
are anticipated.

(11) There are a couple of nits with this document that I believe are correct.

1. There is a reference to an obolete document.  RFC 5246 is referenced because
there is a difference between how "Finished" message is computed between
TLS 1.2 and TLS 1.3.  It is appropriate for this to be called out.

2. The idnits tool calls out I-D.ietf-lamps-rfc5751-bis as being unused,
this is a bug in the tool and the draft is referenced.

3. There is a note to a non-RFC3849-compliant IPv6 address.  This is a false
positive.

(12) There are no formal reviews needed for the document.

(13) All references are marked as normative or informative.  I have no
issues with where they were placed.

(14) Three normative references are made to document currently in process.
All three of these documents have passed Working Group Last call.

(15) There is one downward reference to RFC 5967.  This document is
already listed in the down ref registry.

(16) This is the first version of the document.  There are no modifications
of any existing RFCs from this document.

(17)  I walked the document looking for things that I thought needed to be
registered and then matched this against the registration requests.

(18) There are no new IANA registries created by this document.

(19) There are no formal language sections in the document.
2019-05-07
10 Jim Schaad Responsible AD changed to Benjamin Kaduk
2019-05-07
10 Jim Schaad IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-05-07
10 Jim Schaad IESG state changed to Publication Requested from I-D Exists
2019-05-07
10 Jim Schaad IESG process started in state Publication Requested
2019-05-07
10 Jim Schaad
(1) This is requested to be a Proposed Standard.  This is correctly indicated in the document.

(2) The IESG approval announcement includes a Document Announcement …
(1) This is requested to be a Proposed Standard.  This is correctly indicated in the document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Enrollment over Secure Transport [RFC 7030] provides a REST style
  interface for doing X.509 certificate enrollment as well as other
  operations to support the enrollments.  This document provides a
  set of procedures to run this REST API using DTLS and CoAP rather
  than TLS and HTTP.

Working Group Summary

  Following adoption of the document progress in the WG was
  smooth.  The major issues in terms of formating and structure
  were worked out prior to WG adoption.

Document Quality

  The document has been reviewed and is directly build on
  RFC 7030.  Prior to the document going into last call three
  different groups of implementers got together and had a
  series of virtual inter-op events.  These lead to several changes
  and clarifications in the document as problems were identified. 

Personnel

  Jim Schaad acted as the Document Shepherd and Benjamin Kaduk was
  the Responsible Area Director.

(3) I verified the following:  All of the last call comments were addressed
in some manner, all of the necessary IANA considerations are present, none
of the examples appears to be incorrect from a cursory examination.

(4) I am happy with the review that the document has gotten.

(5) In my opinion the document does not need any broader review.

(6) The following item is a potential concern:

*  The document is using tls-unique for the purpose of channel binding.
I know that there were discussions in the TLS WG about using this or
switching to something else.  I cannot see that they ended up concluding
anything.

The authors have suggested that the correct way to deal with this issue
would be to create an update to RFC 7030, the base EST draft, to start using
the tls-exporter mechanism.

(7)  All authors have confirmed that all appropritae IPR disclosures have been filed.

** van der Stok ** YES - 4/29/19
** Kampanakis ** YES - 5/7/19
** Richardson ** YES - 4/29/19
** Raza ** YES - 4/29/19

(8) There have been no IPR disclosures on this document. 

(9) A reasonable percentage of the active members of the working group
have reviewed the document.  The majority of the reviews were from about
six people.

(10)  There have been no issues with the document.  No future problems
are anticipated.

(11) There are a couple of nits with this document that I believe are correct.

1. There is a reference to an obolete document.  RFC 5246 is referenced because
there is a difference between how "Finished" message is computed between
TLS 1.2 and TLS 1.3.  It is appropriate for this to be called out.

2. The idnits tool calls out I-D.ietf-lamps-rfc5751-bis as being unused,
this is a bug in the tool and the draft is referenced.

3. There is a note to a non-RFC3849-compliant IPv6 address.  This is a false
positive.

(12) There are no formal reviews needed for the document.

(13) All references are marked as normative or informative.  I have no
issues with where they were placed.

(14) Three normative references are made to document currently in process.
All three of these documents have passed Working Group Last call.

(15) There is one downward reference to RFC 5967.  This document is
already listed in the down ref registry.

(16) This is the first version of the document.  There are no modifications
of any existing RFCs from this document.

(17)  I walked the document looking for things that I thought needed to be
registered and then matched this against the registration requests.

(18) There are no new IANA registries created by this document.

(19) There are no formal language sections in the document.
2019-04-28
10 Jim Schaad Tag Revised I-D Needed - Issue raised by WGLC cleared.
2019-04-28
10 Jim Schaad IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-03-11
10 Jim Schaad Added to session: IETF-104: ace  Fri-1050
2019-03-08
10 Panos Kampanakis New version available: draft-ietf-ace-coap-est-10.txt
2019-03-08
10 (System) New version approved
2019-03-08
10 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-03-08
10 Panos Kampanakis Uploaded new revision
2019-02-27
09 Panos Kampanakis New version available: draft-ietf-ace-coap-est-09.txt
2019-02-27
09 (System) New version approved
2019-02-27
09 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-02-27
09 Panos Kampanakis Uploaded new revision
2019-02-06
08 Panos Kampanakis New version available: draft-ietf-ace-coap-est-08.txt
2019-02-06
08 (System) New version approved
2019-02-06
08 (System) Request for posting confirmation emailed to previous authors: Shahid Raza , Michael Richardson , Panos Kampanakis , Peter van der Stok
2019-02-06
08 Panos Kampanakis Uploaded new revision
2019-01-28
07 Jim Schaad Tag Revised I-D Needed - Issue raised by WGLC set.
2019-01-27
07 Jim Schaad Notification list changed to Jim Schaad <ietf@augustcellars.com>
2019-01-27
07 Jim Schaad Document shepherd changed to Jim Schaad
2019-01-13
07 Jim Schaad IETF WG state changed to In WG Last Call from WG Document
2019-01-13
07 Jim Schaad Changed consensus to Yes from Unknown
2019-01-13
07 Jim Schaad Intended Status changed to Proposed Standard from None
2019-01-09
07 Panos Kampanakis New version available: draft-ietf-ace-coap-est-07.txt
2019-01-09
07 (System) New version approved
2019-01-09
07 (System)
Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Sandeep Kumar , Michael Richardson , Peter van der Stok , Martin Furuhed , Panos …
Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Sandeep Kumar , Michael Richardson , Peter van der Stok , Martin Furuhed , Panos Kampanakis , Shahid Raza
2019-01-09
07 Panos Kampanakis Uploaded new revision
2018-10-22
06 Jim Schaad Added to session: IETF-103: ace  Thu-1610
2018-10-08
06 Peter Van der Stok New version available: draft-ietf-ace-coap-est-06.txt
2018-10-08
06 (System) New version approved
2018-10-08
06 (System)
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter van der Stok , Martin Furuhed , …
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter van der Stok , Martin Furuhed , Shahid Raza
2018-10-08
06 Peter Van der Stok Uploaded new revision
2018-07-18
05 Peter Van der Stok New version available: draft-ietf-ace-coap-est-05.txt
2018-07-18
05 (System) New version approved
2018-07-18
05 (System)
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter van der Stok , Martin Furuhed , …
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter van der Stok , Martin Furuhed , Shahid Raza
2018-07-18
05 Peter Van der Stok Uploaded new revision
2018-07-14
04 Roman Danyliw Added to session: IETF-102: ace  Mon-0930
2018-07-02
04 Panos Kampanakis New version available: draft-ietf-ace-coap-est-04.txt
2018-07-02
04 (System) New version approved
2018-07-02
04 (System)
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter Van der Stok , Martin Furuhed , …
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter Van der Stok , Martin Furuhed , Shahid Raza
2018-07-02
04 Panos Kampanakis Uploaded new revision
2018-06-25
03 Peter Van der Stok New version available: draft-ietf-ace-coap-est-03.txt
2018-06-25
03 (System) New version approved
2018-06-25
03 (System)
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter Van der Stok , Martin Furuhed , …
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter Van der Stok , Martin Furuhed , Shahid Raza
2018-06-25
03 Peter Van der Stok Uploaded new revision
2018-06-21
02 Peter Van der Stok New version available: draft-ietf-ace-coap-est-02.txt
2018-06-21
02 (System) New version approved
2018-06-21
02 (System)
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter Van der Stok , Martin Furuhed , …
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter Van der Stok , Martin Furuhed , Shahid Raza
2018-06-21
02 Peter Van der Stok Uploaded new revision
2018-06-06
01 Michael Richardson New version available: draft-ietf-ace-coap-est-01.txt
2018-06-06
01 (System) New version approved
2018-06-06
01 (System)
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter Van der Stok , Martin Furuhed , …
Request for posting confirmation emailed to previous authors: Panos Kampanakis , Sandeep Kumar , Michael Richardson , Peter Van der Stok , Martin Furuhed , Shahid Raza
2018-06-06
01 Michael Richardson Uploaded new revision
2018-06-06
01 Michael Richardson Uploaded new revision
2018-03-13
00 Jim Schaad Added to session: IETF-101: ace  Mon-0930
2018-02-28
00 Jim Schaad This document now replaces draft-vanderstok-ace-coap-est instead of None
2018-02-28
00 Peter Van der Stok New version available: draft-ietf-ace-coap-est-00.txt
2018-02-28
00 (System) WG -00 approved
2018-02-28
00 Peter Van der Stok Set submitter to "Peter van der Stok ", replaces to (none) and sent approval email to group chairs: ace-chairs@ietf.org
2018-02-28
00 Peter Van der Stok Uploaded new revision