Subject: [Curdle] AD Review: draft-ietf-curdle-pkix-04.txt

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 May 2017 12:46:10 -0700

AD Review: draft-ietf-curdle-pkix-04.txt

TECHNICAL
I see that Brian Smith made a number of comments on 4/29. Is the WG
convinced that they have addressed them adequately.

S 5.
The RFC5280 text on {encipher,decipher}Only is kind of obscure.
Say that I have keyAgreement | encipherOnly, can I use this key
for TLS?

   one of the following MAY also be present:

Am I supposed to read from this that no other extension may be
present? I think this should be explicitly stated. The same
applies to signature certificates.

Also, did the WG discuss whether you should mandate keyUsage?

EDITORIAL
S 1.
   HashEdDSA mode with pre-hashing.  The convention used for identifying
   the algorithm/curve combinations are to use the Ed25519 and Ed448 for

convention is

RFC 7748 seems to use "curveXXX" rather than "CurveXXX"

S 4.

    o  subjectPublicKey contains the byte stream of the public key.
      While the encoded public keys for the current algorithms are all
      an even number of octets, future curves could change that.

I know what you mean by "even number" but I think it would be clearer
to say "an exact multiple of 8 bits" so people don't think you are
talking about the parity of the number of bytes.

S 13.
Diffie-Hellman has two ls

-Ekr

---

From: Jim Schaad <[email-masked]>
Date: Mon, 8 May 2017 11:10:57 -0700

Please see in-line

From: Curdle [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, May 5, 2017 12:46 PM
To: curdle <[email-masked]>
Subject: [Curdle] AD Review: draft-ietf-curdle-pkix-04.txt

TECHNICAL

[JLS] I believe that he is probably not happy with the resolution dealing with the requirement to make all of the private keys use either only v1 or v2, however I think that the working group has reached a rough consensus on not making either of these a MUST.   

I need to go through the examples dealing with v2 and erroneous keys that have been supplied, but intend to incorporate them into the document.

S 5.

for TLS?

[JLS] There was no discussion that I remember about the question of mandating the keyUsage extension.  This would end up being deferred to RFC 5280 – so that answer would be no.

I am not sure that this is the correct document to deal with the meaning of the {encipher,decipher}Only bits in key usage.  I cannot remember ever having seen these in practice, unlike the non-Repudiation bit.  If memory serves, I was once told that these bits made more sense for the Royal Holloway than they do for DH or ECDH.  My  personal opinion would be that if you set either of those bits, then the certificate would not be usable for TLS.  (I believe that the question is academic for TLS 1.3 since key agreement certificates are not used anywhere.)  The use of the bits would be for the purpose of doing some type of an authenticated key transport algorithm where the algorithms would be ECDH+HKDF+AES-GCM as a single identified item.

EDITORIAL

S 1.

convention is

[JLS] fixed locally

S 4.

[JLS] Take makes it clearer – done.

S 13.

[JLS] Done

Jim

-Ekr