Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Peter van der Stok <stokcons@bbhmail.nl> Tue, 03 September 2019 12:18 UTC
Return-Path: <stokcons@bbhmail.nl>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A926120132; Tue, 3 Sep 2019 05:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgBoffUMBlxt; Tue, 3 Sep 2019 05:18:26 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5240312012C; Tue, 3 Sep 2019 05:18:26 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id B6CAE1822494D; Tue, 3 Sep 2019 12:18:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=iC1rDGiAcuku9/Fs7h fBdgMzYZF3YPNmgAU/GcxbQps=; b=SqzC+FqMB2lv4cyeyNfVecNsmlbuFTb8M/ mIVEbqyyS/OspJVH9QsCyOtP+Cuo5mAUCIRguqUk0q8NSndV2bSlqcY2wtMbgk6V R59NZVuunvggSkJguMlnSISwqg9tY/nP9lpM3wV1C1TG3g01GBTErFwdVeUaQbt8 13Fz02ZQg=
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::, RULES_HIT:152:355:379:582:599:960:962:967:968:973:988:989:1042:1152:1189:1221:1256:1260:1313:1314:1345:1359:1436:1437:1461:1516:1517:1518:1575:1588:1589:1592:1594:1605:1712:1730:1776:1792:1801:2194:2198:2199:2200:2540:2559:2562:2689:2692:2693:2731:2890:2892:2894:2895:2898:2903:2906:2911:2920:2922:2923:2924:2925:2926:3138:3139:3140:3141:3142:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:4362:4419:4425:4605:4641:4860:5007:6261:6298:6659:6678:6690:7774:7903:7974:8531:8603:8660:8784:8957:9010:9108:9121:10128:10559:10848:11233:11657:11914:12043:12109:12114:12219:12291:12295:12296:12438:12555:12663:12679:12683:12700:12737:12740:12895:12986:13141:13145:13148:13160:13161:13191:13192:13215:13229:13230:13870:13972:14110:14149:14161:14565:14799:21060:21063:21080:21094:21323:21324:21365:21433:21450:21451:21611:21625:21740:21772:21795:21796:21939:30030:30034:30036:30037:30041:30051:30054:30056:30062:30069:30070:3
X-HE-Tag: beast64_f14eede08b20
X-Filterd-Recvd-Size: 70376
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf11.hostedemail.com (Postfix) with ESMTPA; Tue, 3 Sep 2019 12:18:23 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_1c65d4777981c3d61c556925d741d050"
Date: Tue, 03 Sep 2019 14:18:22 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Jim Schaad <ietf@augustcellars.com>, draft-ietf-ace-coap-est.all@ietf.org, consultancy@vanderstok.org, ace@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <6b482aaed0ce510c503984dfbac7286c@bbhmail.nl>
References: <20190828233639.GI84368@kduck.mit.edu> <027701d55ebf$994184b0$cbc48e10$@augustcellars.com> <edcbc2a243cc7118e35aec77b2e1599c@bbhmail.nl> <20190901204340.GG27269@kduck.mit.edu> <6b482aaed0ce510c503984dfbac7286c@bbhmail.nl>
Message-ID: <7cd78133c263214be535ec36734f7ec1@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [5.206.216.229]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/IAXjwpLGl7_C2AXuaba_drn20Yo>
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 12:18:32 -0000
Hi Ben, the last part of the responses to your thorough review. Apart from nits you found some "nice" mistakes. the openssl example make me worry a bit. See below. Peter _______________________________________________________________________ When requesting server-side key generation, the client asks for the server or proxy to generate the private key and the certificate which are transferred back to the client in the server-side key generation response. In all respects, the server SHOULD treat the CSR as it would treat any enroll or re-enroll CSR; the only distinction here is that the server MUST ignore the public key values and signature in the CSR. These are included in the request only to allow re-use of existing codebases for generating and parsing such requests. We need to reword this; the SHOULD is in conflict with the MUST. <pvds> Removed the SHOULD -> "…the server treats the CSR …" </pvds> certificate and a private key. The private key Content-Format requested by the client is depicted in the PKCS#10 CSR request. If nit: I suggest s/depicted/indicated/ <pvds>done </pvds> (Section 5.3) . The two representations (each consisting of two CBOR array items) do not have to be in a particular order since each <pvds> s/do not have to be in a particular order since each representation is/ are/ </pvds> [side note: core-multipart-ct is looking to land on "multipart/mixed" semantics to resolve my outstanding Discuss point; RFC 2046 is pretty clear about the component parts "need[ing] to be in a particular order", which this is in conflict with] representation is preceded by its Content-Format ID. The private key can be in unprotected PKCS#8 [RFC5958] format (Content-Format 284) or protected inside of CMS SignedData (Content-Format 280). The Phrasing it like this makes it soun like the server can just spontaneously decide that it wants to sign the key content, as opposed to having it be dependant on the CSR's contents. Also... <pvds> /The private key/ Dependent on the contents of the CSR, the private key/ </pvds> SignedData is signed by the party that generated the private key, which may be the EST server or the EST CA. The SignedData is further protected by placing it inside of a CMS EnvelopedData as explained in Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted .... if the SignedData is not the outermost container, then we don't care what the relevant Content-Format for it is; we only care about the Content-Format for the EnvelopedData. <pvds> s/ SignedData is signed/SignedData, placed in the outermost container, is signed/ s/ The SignedData is further protected by placing it inside of a CMS EnvelopedData/ SignedData placed within the Enveloped Data does not need additional signing/ </pvds> Also, did we explicitly consider and reject AuthEnvelopedData? <pvds> Not sure about this </pvds> key is included in the encryptedKey attribute in a KEKRecipientInfo structure. 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 nit: hyphenate "client-defined" <pvds> done </pvds> 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 In the key-agreement case, the symmetric key-encryption key is the result of the key-agreement operation, no? In which case it is not itself encrypted, but rather the server's ephemeral public value is sent. <pvds> In RFC7030 the text says: the EnvelopedData content is encrypted using a randomly generated symmetric encryption key (that means ephemeral I assume). The cryptographic strength of the symmetric encryption key SHOULD be equivalent to the clientspecified asymmetric key. However, I see no explicit relation with the ephemeral public value. I don't know what to do here; probably insert the 7030 text. </pvds> public key and is carried in an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. [RFC7030] recommends the use of additional encryption of the returned private key. For the context of this specification, clients and servers that choose to support server-side key generation MUST support unprotected (PKCS#8) private keys (Content-Format 284). Symmetric or asymmetric encryption of the private key (CMS EnvelopedData, Content-Format 280) SHOULD be supported for deployments where end-to-end encryption needs to be provided between the client and a server. Such cases could include architectures where an entity between the client and the CA terminates the DTLS connection (Registrar in Figure 4). This carefully says nothing about recommendations for use, only for software support. Are we letting 7030's recommendation for use of encryption stand? It's probably worth being explicit, either way. <pvds> I did not find any recommendation for use in RFC7030 apart the responsibility of the server for generating random numbers. The recommendations at the top of section 5.8 of the draft seem adequate in my opinion. The alternative is classifying the applications; unless you see a better way to do this. </pvds> Section 6 The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream and initiate EST connections over TLS upstream. The Registrar MUST authenticate and OPTIONALLY authorize the clients and it MUST be <pvds> Suggestion: s/ authenticate and OPTIONALLY authorize the clients and/ authenticate and authorize client request, while/ </pvds> Why OPTIONAL? (Also, nit: OPTIONALLY isn't a 2119 keyword; only OPTIONAL.) client. For example, 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. This is close enough to a literal quote that we might think about actually quoting and using quotation marks. nit: s/POP/PoP/ if we don't do the literal quote. <pvds> Hope my co-authors will react to this </pvds> 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 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 nit: "Such a Registrar" <pvds> done </pvds> the CA. In these cases, the Registrar MUST support random number generation using proper entropy. Not just support -- use! <pvds>done </pvds> Additionally, a conversion from CBOR major type 2 to Base64 encoding MUST take place at the Registrar when server-side key generation is supported. [...] Not always? <pvds> IMO always; removed the when…. </pvds> key, the encrypted CMS EnvelopedData blob MUST be converted to binary in CBOR type 2 downstream to the client. I think we should reword this -- my first reading of "downstream to the client" is "after the client in the processing path", which doesn't actually help the client. Presumably we mean at the registrar, in the downstream direction, towards the client. <pvds> s/ MUST be converted to binary in CBOR type 2 downstream to the client./ MUST be converted at the Registrar to binary CBOR type 2 downstream to the client./ </pvds> The EST-coaps-to-HTTP Registrar MUST support resource discovery according to the rules in Section 5.1. Section 5.1. <pvds> Second section 5.1 is removed </pvds> Do we need to say anything about translation of discovered URIs? <pvds> I don't think so; The Registrar discovers the EST server, while the TLS client discovers the registrar. I don't see the client discovering the EST server through the Registrar </pvds> Section 7 This section addresses transmission parameters described in sections 4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on the CoAP parameters in [RFC7252], but the EST parameter values need to be tuned to the CoAP parameter values. I don't understand what "but the EST parameter values need to be tuned to the CoAP parameter values" means. <pvds> s/ but the EST parameter values need to be tuned to the CoAP parameter values/ but the setting of the CoAP parameter values may have consequences for the setting of the EST parameter values/ </pvds>. 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. A change in a server parameter MUST ensure the adjusted value is also available to all the endpoints with which these adjusted values are to be used to communicate. I don't understand who this is a normative requirement upon. Is it the network operator's, to propagate configuration changes? Or is there supposed to be some automated protocol that makes adjusted values available? <pvds> It is meant as reminder to anyone doing the configuration of a given installation; you want to suppress the text? </pvds> o NSTART: A parameter that controls the number of simultaneous outstanding interactions that a client maintains to a given server. An EST-coaps client is not expected to interact with more than one servers at the same time, which is the default NSTART value defined in [RFC7252]. nit: there's a mismatch between "to a given server" and "more than one servers at the same time". (Also, s/one servers/one server/.) <pvds> s/ not expected to interact with more than one servers at the same time/ /is expected to control at most one interaction with a given server,/ </pvds> o PROBING_RATE: A parameter which specifies the rate of re-sending non-confirmable messages. The EST messages are defined to be sent as CoAP confirmable messages, hence this setting is not applicable. Section 5.4 only has it as RECOMMENDED to send requests in CON messages, so we should still say something here. <pvds> s/ The EST messages are defined to be sent as CoAP confirmable messages, hence this setting is not applicable./ In the rare situations that non-confirmable messages are used, the default PROBING_RATE value defined in RFC7252 applies./ </pvds> Section 9.1 I think we probably need this document as a reference for all the allocations; as the document effectuating the registration, we are still of interest even if most details of content encoding lie elsewhere. Section 9.2 The grammar for these entries is a bit stilted, though the existing registrations are not so far off. nit: should ace.est.att include the word "get" like ace.est.crts does? <pvds> added get </pvds> Section 10.1 The security considerations of Section 6 of [RFC7030] are only partially valid for the purposes of this document. As HTTP Basic Authentication is not supported, the considerations expressed for using passwords do not apply. It may be worth explicitly stating that "the other portions of the security considerations of RFC 7030 continue to apply". <pvds>added </pvds> Modern security protocols require random numbers to be available during the protocol run, for example for nonces, ephemeral (EC) Diffie-Hellman key generation. This capability to generate random nit: the comma expects a 3+ element list but we only have two elements. Just "and" suffices? <pvds>absolutely right </pvds> Analysis SHOULD be done to establish whether server-side key generation increases or decreases the probability of digital identity theft. In the abstract sense, this seems like a non-normative "should". But if we make it apply specifically to those deploying server-side key generation then it is appropriately normative. <pvds> Preceded by: For those deploying server-side key generation, </pvds> 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, air turbulence on the movement of hard drive heads, as pointed out in [PsQs]. Other sources have to be used or nit: need an "and" (or "or") to close the list. <pvds>repaired with or</pvds> 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. Disabling the Implicit Trust Anchor We may want to call out that since the implicit database is used for the initial /crts request, that single jeporadized exchange could cause all subsequent exchanges from that client to be compromised as well. <pvds> before Disabling: "Remark that the initial /crts request uses the implicit database, and that a compromised implicit database has as consequence that all subsequent exchanges from that client are jeopardized." </pvds> database after successfully receiving the Distribution of CA certificates response (Section 4.1.3 of [RFC7030]) limits any risk to the first DTLS exchange. Alternatively, in a case where a /sen request immediately follows a /crts, a client MAY choose to keep the connection authenticated by the Implicit TA open for efficiency reasons (Section 4). A client that pipelines EST-coaps /crts request nit: is "pipelines" the right word here, given that HTTP pipelining is a thing and CoAP pipelining (probably?) isn't, and the former isn't what we're doing anyway? <pvds> suggestion: s/pipelines/interleaves/ <pvds> What's more, POP linking uses tls-unique as it is defined in [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing nit: "such POP linking" or "the CMC POP linking" <pvds>CMC POP </pvds> a man-in-the-middle to leverage session resumption and renegotiation to inject himself between a client and server even when channel binding is in use. The attack was possible because of certain (D)TLS implementation imperfections. In the context of this specification, I don't think we can solely blame the attacks on implementation imperfections (though they were certainly compounding factors). Does this sentence really add any value to the current document? <pvds> Leave this to my co-authors </pvds> binding mechanism. Such a mechanism could include an updated tls- unique value generation like the tls-unique-prf defined in [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such mechanism has not been standardized yet. Adopting a channel binding We probably should be explicit about "using a TLS Exporter value in place of the tls-unique value in the CSR", just from a writing clarity perspective. <pvds> Leave to my co-authors from here to section 10.2 </pvds> It might be worth splitting the triple-handshake bits (including open question) into a separate subsection so that we can make a forward reference to it from earlier in the document. value generated from an exporter would break backwards compatibility. Thus, in this specification we still depend on the tls-unique mechanism defined in [RFC5929], especially since a 3SHAKE attack does not expose messages exchanged with EST-coaps. I suppose that new endpoint names would be one way to work through the backwards-compatibility break, though it's not entirely clear that we need to say so in this document. We probably do want to say that even though EST-coaps looks like a new protocol that could get away with changing the default, we want to preserve the ability for the RA to proxy through to a "classic" EST HTTPS server, so we are in fact constrained to use the compatible choice. Regarding the Certificate Signing Request (CSR), an EST-coaps server is expected to be able to recover from improper CSR requests. What does "recover" mean? Is it just "not crash" or is it expected to somehow still be able to issue a certificate? (If the former, that might be implicit in an RFC 3552 threat model, though saying it explicitly probably doesn't hurt.) Section 10.2 The Registrar proposed in Section 6 must be deployed with care, and only when the recommended connections are impossible. When POP Do we actually explicitly say that the direct connection is recommended anywhere? If not, we should. <pvds> Added at the end of the first paragraph of section 6: When not explicitly needed, it is RECOMMENDED to use direct connections between EST server and client </pvds> linking is used the Registrar terminating the TLS connection establishes a new one with the upstream CA. Thus, it is impossible I think technically it terminates DTLS and esablishes a new TLS connection. <pvds> s/ terminating the TLS connection establishes a new one/ terminating the DTLS connection establishes a new TLS connection/ </pvds> for POP linking to be enforced end-to-end for the EST transaction. The EST server could be configured to accept POP linking information that does not match the current TLS session because the authenticated EST Registrar client has verified this information when acting as an EST server. I think we need to say that the EST server "assumes" or "trusts" that the registrar has verified this information -- it is to some extent a leap of faith. <pvds> Suggestion: s/ client has verified this information when acting as an EST server / acting as an EST-server, assumes that the client has verified this information/ </pvds> The introduction of an EST-coaps-to-HTTP Registrar assumes the client can trust the registrar using its implicit or explicit TA database. I'm not entirely sold on "trust" as the best word here (vs., e.g., validate), but don't object to it. <pvds> leave as is, have no better word </pvds> generating the key. In such cases, the existence of a Registrar requires the client to put its trust on the registrar doing the right thing if it is generating the private key. This is true, though it (probably correctly, for our purposes) does not give any indication of what "the right thing" is intended to be :) <pvds> Remove: "doing the right thing" s/if/when/ </pvds> Section 11.2 I think draft-ietf-lamps-rfc5751-bis, RFC 5958, RFC 8075, and RFC 8422 should be normative references. <pvds>done; </pvds> If we're going to say that this spec requires conformance to RFC 7925's DTLS profile (which we currently don't, but I suggest above that we do), it will need to be a normative reference as well. <pvds> In section 4, /fits into/conforms to/ </pvds> I don't understand why RFC 7231 is in the 'reference' column for application/csrattrs in Table 4; its presence there would normally suggest that it should be a normative reference. <pvds> Removed RFC7231, it is not mentioned in RFC7030 </pvds> RFC 5929 is interesting, as it is of course a normative reference for RFC 7030, which we use normatively, but we may not need to cite it directly as a normative reference from this document. <pvds> Continue to do so </pvds> It may be worth citing RFC 7525 as BCP 195 where it appears. <pvds>To be done </pvds> Appendix A transported in hex, but in binary. The payloads are shown unencrypted. In practice the message content would be transferred over an encrypted DTLS tunnel. I expect a tsvart reviewer to complain about the use of the word "tunnel" here, and suggest "channel" as an alternative. <pvds>done </pvds> The certificate responses included in the examples contain Content- Format 281 (application/pkcs7). If the client had requested Content- Format TBD287 (application/pkix-cert) by querying /est/skc, the server would respond with a single DER binary certificate. Just to check my own understanding: this will always appear within a multipart-core container, right? <pvds> Added: in the multipart-core container </pvds> Appendix A.1 Option (Uri-Port) Option Delta = 0x4 (option# 3+4=7) Option Length = 0x4 Option Value = 9085 Option (Uri-Path) Option Delta = 0x4 (option# 7+4=11) Option Length = 0x5 Option Value = "est" This is more for my own edification than the document's sake, so thank you for your time, but what accounts for the "extra" length here? The "est" is three bytes, and what makes up for the other two? Also, I assume that the port value of 9805 is the decimal value, which gets CBOR encoded into two bytes of integer encoding plus the byte with additional information 25 to indicate the two-byte integer, and another byte that I need help accounting for. <pvds> Many thanks; an old misreading of an example in 7252. For the option length of URI-Path we included the quotations as well; That is WRONG. Repaired it everywhere. Options are not CBOR encoded. </pvds> Appendix A.2 Do we want to say anything about the IDevID in the CSR/cert? I note that the breakdown in Appendix C.2 (looks like openssl output) does not decode the otherName (though asn1parse can be convinced to do so). <pvds> What do you suggest for IDevID? Actually openssl was used extensively for generating the examples. Will be happy to learn about otherName </pvds> Appendix A.3 I'm having trouble validating the private key in the PKCS#8 component: asn1parse says: <pvds> As input I used recently a hex dump of Wt1234.key.der: 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 6b020101042061336a86ac6e7af4a96f632830ad4e6aa0837679206094d7 679a01ca8c6f0c37a14403420004c8b421f11c25e47e3ac57123bf2d9fdc 494f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95 cf75f602f9152618f816a2b23b5638e59fd9 I used openssl pkey -in Wt1234.key.der -text -noout -inform der\ -passin pass:watnietweet The password is may be prohibitive? Resulting in: Private-Key: (256 bit) priv: 61:33:6a:86:ac:6e:7a:f4:a9:6f:63:28:30:ad:4e: 6a:a0:83:76:79:20:60:94:d7:67:9a:01:ca:8c:6f: 0c:37 pub: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 56:38:e5:9f:d9 ASN1 OID: prime256v1 NIST CURVE: P-256 $ unhex|openssl asn1parse -inform der 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 cd33f3c1846e304f1717f8123f1a284cc99f 0:d=0 hl=3 l= 135 cons: SEQUENCE 3:d=1 hl=2 l= 1 prim: INTEGER :00 6:d=1 hl=2 l= 19 cons: SEQUENCE 8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 17:d=2 hl=2 l= 8 prim: OBJECT :prime256v1 27:d=1 hl=2 l= 109 prim: OCTET STRING [HEX DUMP]:306B02010104200B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6A144034200041BB8C1117896F98E4506C03D70EFBE820D8E38EA97E9D65D52C8460C5852C51DD89A61370A2843760FC859799D78CD33F3C1846E304F1717F8123F1A284CC99F which doesn't look like an RFC5208 PrivateKeyInfo: PrivateKeyInfo ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] IMPLICIT Attributes OPTIONAL } Version ::= INTEGER PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKey ::= OCTET STRING Attributes ::= SET OF Attribute due to the lack of OID for privateKeyAlgorithm, etc. (`openssl pkcs8` also chokes on it, but I don't have a working example and can't rule out user error there.) Even that giant OCTET STRING 27 bytes in doesn't seem to match a PrivateKeyInfo: $ unhex|openssl asn1parse -inform der -strparse 27 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 cd33f3c1846e304f1717f8123f1a284cc99f 0:d=0 hl=2 l= 107 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :01 5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 39:d=1 hl=2 l= 68 cons: cont [ 1 ] 41:d=2 hl=2 l= 66 prim: BIT STRING though the OCTET STRING does have the private key and the BIT STRING has the public key's contents as depicted in C.3 (details of that too boring to show). So I have to wonder if I'm messing something up, somewhere. Section A.4 I'm not sure how useful repeating the RFC 7030 csrattrs is: do we expect (e.g.) brainpoolP384r1 to be relevant for our readers? <pvds> It was added for completeness sake; nothing more. Suppressing it may provoke other questions like: Why is it not there? </pvds> Appendix B.1 and BLOCK option Block2. The minimum PMTU is 1280 bytes, which is the example value assumed for the DTLS datagram size. The example I'm not seeing how this relates to the rest of the section. <pvds> I see. We do not use it anymore.; suppressed it. </pvds> The CoAP message adds around 10 bytes, the DTLS record 29 bytes. To avoid IP fragmentation, the CoAP Block The DTLS overhead can also vary based on cipher suite, padding, etc., so a bit more qualification ("we assume", "around", etc.) might be in order. <pvds> Added: "in this example" </pvds> tenth packet of 63 bytes. The client sends an IPv6 packet containing the UDP datagram with the DTLS record that encapsulates the CoAP request 10 times. The server returns an IPv6 packet containing the UDP datagram with the DTLS record that encapsulates the CoAP response. The CoAP request-response exchange with block option is The definite vs. indefinite articles here don't seem quite right, and each of the 10 datagrams do not encapsulate the entire CoAP request. <pvds> I don't understand your meaning. </pvds> with exponent (2**(SZX+4)) separated by slashes. The Length 64 is used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent We just said "to avoid IP fragmentation" ten lines ago. <pvds> Removed </pvds> Should we be using the same Token value in two different exchanges in this document? <pvds> No opinion </pvds> Appendix B.2 In this example, the requested Block2 size of 256 bytes, required by the client, is transferred to the server in the very first request message. The block size 256=(2**(SZX+4)) which gives SZX=4. The I don't see a Block2 size in the first request message, just Block1: <pvds> Thanks. Block1 it is </pvds> POST [2001:db8::2:321]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> <-- (ACK) (1:0/1/256) (2.31 Continue) Also, we seem to have stopped using the "{CSR req frag#2}" notation that we had in the main body text. <pvds>That is an oversight; adapted </pvds> Appendix C.2 [I mentioned otherName's non-decoding earlier] Appendix C.3 I find it kind of amusing that we have a "Netscape Comment" in the generated cert :) <pvds> This was the result of a lengthy openssl struggle. Any suggestions for improvement are very welcome indeed. </pvds> _
- [Ace] AD review of draft-ietf-ace-coap-est-12 Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Michael Richardson
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Michael Richardson
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Panos Kampanakis (pkampana)
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Panos Kampanakis (pkampana)
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Panos Kampanakis (pkampana)