Changes for Secdir review

draft-ietf-ace-coap-est.xml

@@ -51,7 +51,7 @@
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>
 
-<rfc category="std" ipr="trust200902" docName="draft-ietf-ace-coap-est-15">
+<rfc category="std" ipr="trust200902" docName="draft-ietf-ace-coap-est-16">
   <front>
     <title abbrev="EST-coaps">EST over secure CoAP (EST-coaps)</title>
     <author fullname="Peter van der Stok" initials="P." surname="van der Stok">
@@ -129,6 +129,12 @@
 
   <section anchor="changes" title="Change Log">
    <t>EDNOTE: Remove this section before publication</t>
+   <t> -16
+    <list style="empty">
+	   <t>Updates to address Yaron S.'s Secdir review.</t>
+	   <t>Updates to address David S.'s Gen-ART review.</t>
+    </list>
+   </t>
    <t> -15
     <list style="empty">
 	   <t>Updates to addressed Ben's AD follow up feedback.</t>
@@ -404,7 +410,7 @@ HMAC(finished_key,
 
    <t>In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction. Authenticating and negotiating DTLS keys requires resources on low-end endpoints and consumes valuable bandwidth. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions. For example, an EST csrattrs request that is followed by a simpleenroll request can use the same authenticated DTLS connection. However, when a cacerts request is included in the set of sequential EST transactions, some additional security considerations apply regarding the use of the Implicit and Explicit TA database as explained in <xref target="sec-est"/>.</t>
 
-   <t>Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other. In some cases, like NAT rebinding, keeping the state of a connection is not possible when devices sleep for extended periods of time. In such occasions, <xref target="I-D.ietf-tls-dtls-connection-id"/> negotiates a connection ID that can eliminate the need for new handshake and its additional cost; or DTLS 1.3 session resumption provides a less costly alternative than re-doing a full DTLS handshake. </t>
+   <t>Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other. In some cases, like NAT rebinding, keeping the state of a connection is not possible when devices sleep for extended periods of time. In such occasions, <xref target="I-D.ietf-tls-dtls-connection-id"/> negotiates a connection ID that can eliminate the need for new handshake and its additional cost; or DTLS session resumption provides a less costly alternative than re-doing a full DTLS handshake. </t>
   </section>  <!-- 7925 profile  -->
 
 
@@ -636,8 +642,8 @@ representations. -->
    <c> /skc  </c>   <c>   280  </c>   <c>  TBD287</c>
 </texttable>
 
-<t>The key and certificate representations are ASN.1 encoded
-	  in binary format. An example is shown in <xref target="appskg"/>.</t>
+<t>The key and certificate representations are DER-encoded ASN.1, 
+   in its native binary form. An example is shown in <xref target="appskg"/>.</t>
 
       <!-- </section> -->  <!--Content-Format application/multipart-core -->
 
@@ -961,12 +967,7 @@ POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256)          -->
 	it could be configured to accept PoP linking information that does not match
 	the current TLS session because the authenticated EST client Registrar has
 	verified this information when acting as an EST server".</t>
-	<t>For some use-cases, clients that leverage server-side key generation might
-	prefer for the enrolled keys to be generated by the Registrar if the CA does not
-	support server-side key generation. Such a Registrar is responsible
-	for generating a new CSR signed by a new key which will be returned to the
-	client along with the certificate from the CA. In these cases, the Registrar 
-	MUST use random number generation with proper entropy. </t>
+
 
     <t><xref target="est-uri"/> contains the URI mappings between EST-coaps and EST
 	that the Registrar MUST adhere to. <xref target="codes"/> of this
@@ -979,6 +980,15 @@ POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256)          -->
 	CMS end-to-end encryption is employed for the private key, the encrypted
 	CMS EnvelopedData blob MUST be converted at the Registrar to binary CBOR 
 	type 2 downstream to the client. </t>
+
+	<t>A deviation from the mappings in <xref target="est-uri"/> could take place if 
+	clients that leverage server-side key generation preferred for the enrolled 
+	keys to be generated by the Registrar in the case the CA does not
+	support server-side key generation. Such a Registrar is responsible
+	for generating a new CSR signed by a new key which will be returned to the
+	client along with the certificate from the CA. In these cases, the Registrar 
+	MUST use random number generation with proper entropy. </t>
+
 	<t>Due to fragmentation of large messages into blocks, an EST-coaps-to-HTTP
 	Registrar MUST reassemble the BLOCKs before translating the binary content to
 	Base64, and consecutively relay the message upstream. </t>
@@ -1168,7 +1178,7 @@ security considerations of <xref target="RFC7030"/> continue to apply.</t>
       <t>Regarding the Certificate Signing Request (CSR), <!--an adversary could exclude
 	  attributes that a server may want, include attributes that a server may not want,
 	  and render meaningless other attributes that a server may want. T-->an EST-coaps 
-      server is expected to be able to recover from improper CSR requests. </t>
+      server is expected to be able to recover from improperly formatted CSR requests. </t>
       <t>Interpreters of ASN.1 structures should be aware of the use of invalid ASN.1
 	  length fields and should take appropriate measures to guard against buffer overflows,
 	  stack overruns in particular, and malicious content in general.</t>