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 |