Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> 
> Sent: Wednesday, September 4, 2019 12:02 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; 'Benjamin Kaduk' <[e-mail]>; [e-mail]; [e-mail]
> 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 <[e-mail] <mailto:[e-mail]> > 
> Sent: Tuesday, September 3, 2019 5:18 AM
> To: Benjamin Kaduk <[e-mail] <mailto:[e-mail]> >
> Cc: Jim Schaad <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
> 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>
> 
> 
> 
>