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

Reply via email to