Hi Jim, Thanks for taking a closer look. It's been a long week, so I'm not sure if you're saying that I was doing the decoding wrong, expecting the wrong structure, or both.
-Ben On Wed, Sep 04, 2019 at 11:02:31AM -0700, Jim Schaad wrote: > Let me draw back and re-address the comment from Ben about the private key in > appendix A.3 > > > > If I take > > > > 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 > > 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 > > 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 > > 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 > > cd33f3c1846e304f1717f8123f1a284cc99f > > > > and decode it I get (with comments from me) > > > > SEQUENCE (3 elem) -- OneAsymmetricKey (replacement of PKCS #8) > > INTEGER 0 -- Version = v1 > > SEQUENCE (2 elem) -- privateKeyAlgorithm > > OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key > type) -- Alg ID > > OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named > elliptic curve) – Parameters == P256 > > OCTET STRING (1 elem) – Private Key > > SEQUENCE (3 elem) – ECPrivate Key [RFC 5915] > > INTEGER 1 – Version – ecPrivkeyVer1 > > OCTET STRING (32 byte) > 0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 – Private > Key value > > [1] (1 elem) – Public key value > > BIT STRING (520 bit) > 0000010000011011101110001100000100010001011110001001011011111001100011… > > > > > > This looks correct to me. > > > > Jim > > > > > > > > > > From: Peter van der Stok <stokc...@bbhmail.nl> > Sent: Wednesday, September 4, 2019 12:02 AM > To: Jim Schaad <i...@augustcellars.com> > Cc: consulta...@vanderstok.org; 'Benjamin Kaduk' <ka...@mit.edu>; > draft-ietf-ace-coap-est....@ietf.org; ace@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > > > I concluded on the pruned . > > Peter > > Jim Schaad schreef op 2019-09-03 20:48: > > I have pruned and tossed in a few [JLS] comments. > > > > Jim > > > > > > From: Peter van der Stok <stokc...@bbhmail.nl <mailto:stokc...@bbhmail.nl> > > Sent: Tuesday, September 3, 2019 5:18 AM > To: Benjamin Kaduk <ka...@mit.edu <mailto:ka...@mit.edu> > > Cc: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >; > draft-ietf-ace-coap-est....@ietf.org > <mailto:draft-ietf-ace-coap-est....@ietf.org> ; consulta...@vanderstok.org > <mailto:consulta...@vanderstok.org> ; ace@ietf.org <mailto:ace@ietf.org> > Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > > > 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 > _______________________________________________________________________ > > > 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 > > [JLS] As a CMS person, I would consider the use of EnvelopedData and > AuthEnvelopedData to be equivalent. Which of these is used is totally > dependent on what algorithm is used for encryption. If one requires the use > of AES-GCM or AES-CCM then one has no choice but to use AuthEnvelopedData. > If one wants to use AES-CCM ten one has no choice but to use EnvelopedData. > Everybody is slowly moving from EnvelopedData to AuthEnvelopedData just > because everybody is changing algorithms. I do not remember any discussions > about this, but AuthEnvelopeData is generally going to be the more correct > value here. I will also note that there is a space between Enveloped and > Data which is not CMS. > > <pvds2> > I don't do anything here > </pvds2> > > </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. > > [JLS] Ben, you do not have the correct view of the key-agreement case. It > does a key agreement -> KDF -> KeyWrap -> Content. There is always a key > wrap step between the key agreement and the content encryption key. > <pvds2> > Also here I see no room for improvement then. > <pvds2> > > </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> > > > > > > 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 > > [JLS] I would disagree with the nit. > > [JLS] I would agree with the nit on OPTIONALLY being wrong, but I think that > it ought to be at least a SHOULD if not a MUST for the use of COAPS as it is > terminating the connection. The only exception would be in there is internal > authentication for the EST request. > <pvds2> > Suggest to use SHOULD and not distinguish between terminating or not. > <pvds2> > > </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. > > [JLS] No response from Peter? > <pvds2> > Sorry, misunderstood. Will add <thisdocument> > </pvds2> > > > 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 > > [JLS] I would lose the password on the key if possible. > > <pvds2> > Right, It means changing the whole chain of certificates. and redoing the > examples. > But I understand the reason, being confronted with the disassembly failure. > </pvds2> > > 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. > > > > > > > Appendix B.1 > > > > > > > Should we be using the same Token value in two different exchanges in > this document? > > <pvds> > > No opinion > > [JLS] As long as the Token values are not in the same exchange, this makes no > difference. Tokens are reused after an amount of time in CoAP. > > <pvds2> > No extra text, I gather > </pvds2> > > </pvds> > > > > _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace