Hi Jim,
I removed the passwd from the example, and did the disassembly as Ben
proposed.
That seems to work correctly for me.
308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
6b020101042061336a86ac6e7af4a96f632830ad4e6aa0837679206094d7
679a01ca8c6f0c37a14403420004c8b421f11c25e47e3ac57123bf2d9fdc
494f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95
cf75f602f9152618f816a2b23b5638e59fd9
Peter
Jim Schaad schreef op 2019-09-04 20:02:
> 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>
>> SENT: Tuesday, September 3, 2019 5:18 AM
>> TO: Benjamin Kaduk <ka...@mit.edu>
>> CC: Jim Schaad <i...@augustcellars.com>;
>> draft-ietf-ace-coap-est....@ietf.org; consulta...@vanderstok.org;
>> 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_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
