Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

From: David Schinazi <[email-masked]>
Date: Mon, 03 Apr 2017 11:25:44 -0700

Thanks for the update!

I've reviewed -04 and I think the draft is ready to move forward.

Regards,
David Schinazi

> On Mar 28, 2017, at 15:43, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
> Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday.  Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. 
> 
> Yours, 
> Daniel
> 
> -----Original Message-----
> From: Curdle [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Tuesday, March 28, 2017 4:40 PM
> To: [email-masked]
> Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt
> 
> Here is the promised updated draft.
> 
> Changes:
> 1.  Fixed an example that David Benjamin found was wrong.  (Incorrect sign bit in public key.) 2.  Remove all of the pre-hash text except to note that it does exist.
> 3.  No changes to the OID arc being used despite the agreement during the meeting.  After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur.  The problem was only with getting new values assigned not with the current values which were already assigned.
> 
> That should be the final issues in the draft
> 
> Jim
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, March 28, 2017 4:31 PM
>> To: Jim Schaad <[email-masked]>; Simon Josefsson 
>> <[email-masked]>
>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt
>> 
>> 
>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been 
>> successfully submitted by Jim Schaad and posted to the IETF repository.
>> 
>> Name:		draft-ietf-curdle-pkix
>> Revision:	04
>> Title:		Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for
>> use in the Internet X.509 Public Key Infrastructure
>> Document date:	2017-03-28
>> Group:		curdle
>> Pages:		15
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04
>> 
>> Abstract:
>>   This document specifies algorithm identifiers and ASN.1 encoding
>>   formats for Elliptic Curve constructs using the Curve25519 and
>>   Curve448 curves.  The signature algorithms covered are Ed25519 and
>>   Ed448.  The key agreement algorithm covered are X25519 and X448.  The
>>   encoding for Public Key, Private Key and EdDSA digital signature
>>   structures is provided.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
> 
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 04 Apr 2017 08:39:23 -0700

I've gone through my review of the draft as well, and I think this version looks good!

Thanks,
Tommy

> On Apr 3, 2017, at 11:25 AM, David Schinazi <[email-masked]> wrote:
> 
> Thanks for the update!
> 
>> On Mar 28, 2017, at 15:43, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>

---

From: "Mehner, Carl" <[email-masked]>
Date: Sat, 22 Apr 2017 05:09:37 +0000

> From: TLS [mailto:[email-masked]] On Behalf Of Daniel Migault
> Hi,
> 
> Thank you Jim for the update. Here is the version resulting from the
> discussion we had during the WG meeting yesterday.  Please review the
> document and provide your feed backs by April 4 so we can move the draft
> to the IESG.

It is a bit past April 4, and I apologize, but I just ran into this...

Should the "kaa-X488 KEY-AGREE ::= {"  in the ASN.1 module in section 9
instead be "kaa-X448 KEY-AGREE ::= {" ?

Also, in section 13, I believe it is Hellman with 2 l's.

> 1.  Fixed an example that David Benjamin found was wrong.  (Incorrect sign
> bit in public key.) 2.  Remove all of the pre-hash text except to note
that it
> does exist.
> 3.  No changes to the OID arc being used despite the agreement during the
> meeting.  After the meeting, Russ, the chairs and I had a short talk and
> decided that this did not need to occur.  The problem was only with
getting
> new values assigned not with the current values which were already
> assigned.
> 
> > Title:		Algorithm Identifiers for Ed25519, Ed448, X25519 and
X448
> for
> > URL:            https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dcurdle-2Dpkix-
> 2D04.txt&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0
> f1hEhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSy
> h8nYxBD-rwM&s=wcttUJysVcLmWQ7svq2t0Nb41NgIbfjIjSeBfaduLDI&e=
> > Status:         https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcurdle-
> 2Dpkix_&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0f
> 1hEhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSy
> h8nYxBD-rwM&s=A8_G31FWl2kykg3GSF6HdI-2ScdRpyZUQGbtm1EGXtE&e=
> > Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dcurdle-2Dpkix-
> 2D04&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0f1h
> EhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8
> nYxBD-rwM&s=sZ2jebdsB7X7grNhRfcOW5E4q4_hNA5PUh9hakL3MIc&e=
> > Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dcurdle-2Dpkix-
> 2D04&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0f1h
> EhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8
> nYxBD-rwM&s=UhQ7p4MbELlnuap0ja0gIWlTuwzpH9h7QDzxz-1wkg8&e=
> > Diff:           https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dcurdle-2Dpkix-
> 2D04&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0f1h
> EhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8
> nYxBD-rwM&s=8Le8SB-M-UikBklTudIyLmY350YCLZcMS-xBwHhK3Ic&e=
> >
> > Abstract:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_curdle&d=DwICAg&c=4VfW4Y7UDKzr0
> jHM1Tk29w&r=7jcwf_nHftJUeeRf0f1hEhoYPns7FKYpnjAfuly83Yc&m=2Amsy
> wb3tVWXtWhbKQaG2UsB1UqsdOSyh8nYxBD-rwM&s=-
> QGwR6ZMLxm7fInDxqNaE6ufW9_LkeZQjADdOHyYoVM&e=
> 
> TLS mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=4VfW4Y7UDKzr0jHM
> 1Tk29w&r=7jcwf_nHftJUeeRf0f1hEhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3t
> VWXtWhbKQaG2UsB1UqsdOSyh8nYxBD-rwM&s=y_nDnvAU07Nn8Pnxx-
> SOP_Hqm0ZBXlyYa9-eO-LGnZQ&e=

---

From: Russ Housley <[email-masked]>
Date: Sun, 23 Apr 2017 11:46:13 -0400

That looks like a typo to me, I’m glad we have time to correct it.

Russ

> On Apr 22, 2017, at 1:09 AM, Mehner, Carl <[email-masked]> wrote:
>

---

From: Brian Smith <[email-masked]>
Date: Sat, 29 Apr 2017 15:31:18 -1000

> url2=draft-ietf-curdle-pkix-04

I started implementing this this weekend and I noticed that this is the
only private key format for which it is impossible to implement a useful
pairwise consistency check. In one sense, a consistency check isn't
necessary because the public key is computed from the private key, so
there's no room for inconsistency. On the other hand, there's no way to
detect corruption of the private key like you can with RSA and ecPublicKey
keys, when the key is stored in the unencrypted form. I think this is
really unfortunate.

It is possible to use a v2 PKCS#8 encoding that adds the publicKey
component, in which case one can then implement an integrity check.

However, unless this is documented in the draft one way or another as a
MUST accept or a MUST NOT generate, I think it will be an interop
nightmare. In particular, we should avoid the situation where some
implementations produce v2 keys so they can add the publicKey field, and
where other implementations reject v2 keys because they only parse v1,
where the publicKey field isn't allowed.

In particular, it is important for the spec to include v2 PKCS#8 examples
with the publicKey field, if such encoding is allowed.

I also found that, if the publicKey field is included, and one tries to do
pairwise validation of the private key and public key, there are a few
special cases that should be documented as test vectors.

Cheers,
Brian

---

From: Jim Schaad <[email-masked]>
Date: Sun, 30 Apr 2017 11:27:55 +0200

From: Brian Smith [mailto:[email-masked]] 
Sent: Sunday, April 30, 2017 3:31 AM
To: Jim Schaad <[email-masked]>
Cc: curdle <[email-masked]>
Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt

Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04

I started implementing this this weekend and I noticed that this is the only private key format for which it is impossible to implement a useful pairwise consistency check. In one sense, a consistency check isn't necessary because the public key is computed from the private key, so there's no room for inconsistency. On the other hand, there's no way to detect corruption of the private key like you can with RSA and ecPublicKey keys, when the key is stored in the unencrypted form. I think this is really unfortunate.

[JLS] It is true that RSA has this as a built in feature, however it is not true for all of the key formats that are in common use today.  The same structure is used here as is used for traditional DH keys.  The ability to do check that the public and private keys match is something that is possible, but is frequently not done even for RSA keys.  Additionally, there are cases where it is less expensive to re-compute the public key than to transport it.  It is not always possible to detect corruption when you store in an unencrypted form.  It would also not be possible to know if it was the private key or the public key that has been corrupted, just that the two values do not match.

It is possible to use a v2 PKCS#8 encoding that adds the publicKey component, in which case one can then implement an integrity check.

However, unless this is documented in the draft one way or another as a MUST accept or a MUST NOT generate, I think it will be an interop nightmare. In particular, we should avoid the situation where some implementations produce v2 keys so they can add the publicKey field, and where other implementations reject v2 keys because they only parse v1, where the publicKey field isn't allowed.

[JLS]  I have not heard that this is an issue today with DH keys.  This makes me think that this is not going to be a big issue.  I expect that most implementations would all for parsing v2 keys even if they then ignore the public key field.

In particular, it is important for the spec to include v2 PKCS#8 examples with the publicKey field, if such encoding is allowed.

[JLS] This is a reasonable request.  I will look at adding this as part of the IETF last call comments.

I also found that, if the publicKey field is included, and one tries to do pairwise validation of the private key and public key, there are a few special cases that should be documented as test vectors.

[JLS] Please be more explicit on what you believe are the special cases that need to be highlighted.  The cases that immediately come to mind for me are the question of correct form for the values, but that is not an encoding problem but an issue with the library being used.  Are there others that you have in mind?

Jim

Cheers,

Brian

---

From: Brian Smith <[email-masked]>
Date: Sun, 30 Apr 2017 14:15:56 -1000

Jim Schaad <[email-masked]> wrote:
> Brian Smith wrote:
> > I started implementing this this weekend and I noticed that this is
> > the only private key format for which it is impossible to implement
> > a useful pairwise consistency check. In one sense, a consistency
> > check isn't necessary because the public key is computed from
> > the private key, so there's no room for inconsistency. On the
> > other hand, there's no way to detect corruption of the private key
> > like you can with RSA and ecPublicKey keys, when the key is
> > stored in the unencrypted form. I think this is really unfortunate.
>
> [JLS] It is true that RSA has this as a built in feature, however it
> is not true for all of the key formats that are in common use today.
> The same structure is used here as is used for traditional DH keys.

It seems to me that traditional DH keys are exceptional in this
respect. ECPrivateKey (for ECDSA and ECDH) is required to contain the
public key. RSAPrivateKey contains everything needed to validate it.

>  The ability to do check that the public and private keys match is something that is possible, but is frequently not done even for RSA keys.  Additionally, there are cases where it is less expensive to re-compute the public key than to transport it.

Doing the consistency check vs. saving space is a safety trade-off.

> It is not always possible to detect corruption when you store in an unencrypted form.

What kind of corruption would we not be able to detect? It is possible
that somehow the private key could get corrupted and that there could
be a corresponding corruption to the public key such that they match
again, but this seems extremely unlikely unless somebody simply
replaced the key pair with another key pair.

> It would also not be possible to know if it was the private key or the public key that has been corrupted, just that the two values do not match.

This is the case with any kind of cryptographic check, including HMAC
or whatnot.

> > However, unless this is documented in the draft one way or
> another as a MUST accept or a MUST NOT generate, I think
> it will be an interop nightmare. In particular, we should avoid
> the situation where some implementations produce v2 keys
> so they can add the publicKey field, and where other
> implementations reject v2 keys because they only parse v1,
> I have not heard that this is an issue today with DH keys.  This
> makes me think that this is not going to be a big issue.  I expect
> that most implementations would all for parsing v2 keys even if
> they then ignore the public key field.

If that's the expectation then let's enshrine that in the spec by
saying that implementations MUST accept v2 keys for these types of
keys.

In particular, I have seen PKCS#8 implementations that reject any v2
PKCS#8 file instead of ignoring the extra fields.

> > In particular, it is important for the spec to include v2 PKCS#8
> > examples with the publicKey field, if such encoding is allowed.
>
> This is a reasonable request.  I will look at adding this as part of the IETF last call comments.

Thanks.

> I also found that, if the publicKey field is included, and one tries to
> do pairwise validation of the private key and public key, there are
> a few special cases that should be documented as test vectors.

> [JLS] Please be more explicit on what you believe are the special
> cases that need to be highlighted.  The cases that immediately
> come to mind for me are the question of correct form for the values,
> but that is not an encoding problem but an issue with the library
> being used.  Are there others that you have in mind?

I'll use X25519 as an example.

RFC 7748 says:
> When receiving such an array, implementations of X25519 (but
> not X448) MUST mask the most significant bit in the final byte."

Thus for every X25519 key, there will be at least two possible
encodings of the public key. We should have test vectors such
that both encodings of the same public key (for the same private
key) are included as separate vectors, to ensure that any
implementation that does do a pairwise consistency check
includes the masking step in the comparison.

Similarly, for ~19 X25519 keys, there are twice as many (4)
possible encodings of the public key:

1. High bit is 0, fully reduced.
2. High bit is 1, not fully reduced.
3. High bit is 0, fully reduced.
4. High bit is 0, not fully reduced.

We should have test vectors for all four cases, to ensure that any
implementation that does the pairwise consistency check does the
comparison on the fully-reduced value of the given and calculated
public key, instead of just doing a bytewise comparison. (Though, do
we know any of the these 19 private keys that could use to produce a
test vector?)

Cheers,
Brian
-- 
https://briansmith.org/