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
