Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal

From: Daniel Migault <[email-masked]>
Date: Tue, 7 Jun 2016 16:58:28 -0400

Hi,

Do we have some consensus that having top-level OID would be better ?
Please provide your opinion and let the WG know your thoughts so the
document can be moved forward.

BR,
Daniel

On Thu, May 19, 2016 at 10:41 AM, David Benjamin <[email-masked]>
wrote:

> On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos <[email-masked]>
> wrote:
>
>> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote:
>> > I would actually advocate a different change. I sent this message
>> > earlier:
>> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html
>> >
>> > Rather than use parameters, allocate new algorithm OIDs for
>> > everything. I don't think we actually gain anything by exposing the
>> > relations and parameterizations between these algorithms. When
>> > implementing, they are great for sharing code. But when consuming,
>> > exposing it makes parsing more complex, and it increases the risk of
>> > reusing keys between related algorithms. We can get the best of both
>> > worlds by separating entry-points and sharing internals.
>>
>> On your referenced message I am confused on the issue you raise on
>> section 3. As I read section 3, I do not see anything that allows
>> having id-ecPublicKey as an algorithm identifier for these keys.
>>
>
> It's certainly possible I'm misunderstanding what section 3 was for. I was
> kind of confused why there were two encodings. I was getting id-ecPublicKey
> from:
>
> """
>    Section 2.3.5 of [RFC3279]
>    describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID.
>    This OID has the associated EcpkParameters parameters structure,
>    which contains the namedCurve CHOICE.  Here we introduce two [I think
> this should be four] new OIDs
>    for use in the namedCurve field.
> """
>
> Anyway, if we go with top-level OIDs for everything, this is all moot.
>
> David
>
>
>> Other than this part, you raise a very good point. It may be much
>> simpler to use a common OID and move it up. Unlike the NIST curves the
>> constructions we have under the eddsa OID umbrella are quite distinct.
>>
>> I was concerned about future extensibility and the fact that pureEdDSA
>> and PrehashedEdDSA could be with separate algorithm OIDs, but after
>> thinking it further, I think what you suggest is much neater, as having
>> a single OID to identify scheme+curve will also restrict private keys
>> to a single purpose which is a good thing.
>>
>> +1
>>
>> regards,
>> Nikos
>>
>>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>
>

---

From: Brian Smith <[email-masked]>
Date: Tue, 7 Jun 2016 11:47:40 -1000

I assume you are referring to this proposal from David Benjamin:

>  I'd suggest four separate parameter-less algorithm OIDs for ed25519,
> ed25519ph, ed448, and ed448ph. (Of course, specify whether the parameters
> are omitted or NULL.) Likewise, if anyone wants X25519 or X448
> certificates, allocate those too.

I very much support this proposal. It's best to keep things simply by not
using parameters. The spec. should say that the parameters are omitted,
because encoding a NULL is just wasting two bytes for no reason.

I would love to see a new draft with this proposal incorporated.

Also, I would like to see some test vectors for Ed25519 (non-prehash). As
soon as I get those test vectors then I will add support for Ed25519 to my
implementation, webpki [1] so that others can use it for interop testing.

[1] https://github.com/briansmith/webpki

Cheers,
Brian

---

From: David Benjamin <[email-masked]>
Date: Tue, 07 Jun 2016 22:28:02 +0000

> because encoding a NULL is just wasting two bytes for no reason.

Omitting sounds good to me. I doubt matching RSA in including a NULL would
actually result in code savings for anyone, which is the only argument I
can see for it. Unless we somehow end up losing id-ecPublicKey and
id-RSASSA-PSS before id-rsaEncryption.

If this proposal does end up being the consensus, I would suggest
afterwards there should be an even stronger document to deprecate the
parameters field in AlgorithmIdentifier altogether for new things. I've
never seen a use that, in my opinion, didn't turn out to be a mistake.

> I would love to see a new draft with this proposal incorporated.

Another question is what to do with the signature algorithms. I could
imagine doing:
a) id-EdDSASignature as in the draft
b) Use the same OIDs as the keys
c) Define a parallel set of OIDs

I don't like (a) for the same reasons I don't like the keys sharing OIDs.
It's also nice to be able to determine the signature algorithm used without
the issuer on hand. (I've more than once had difficulties looking through
ECDSA certs in the CT log because of this.)

I don't really care between (b) and (c). RSA-PSS uses the same OID for
both, which suggests (b). I suppose (c) avoids a "type mismatch" in OIDs,
but I'm not sure that matters.

---

From: Brian Smith <[email-masked]>
Date: Tue, 7 Jun 2016 12:37:55 -1000

David Benjamin <[email-masked]> wrote:
> Brian Smith <[email-masked]> wrote:
>

> I don't really care between (b) and (c). RSA-PSS uses the same OID for both,
> which suggests (b). I suppose (c) avoids a "type mismatch" in OIDs, but I'm
> not sure that matters.

I suggest using the same OID for both, as RSA-PSS does. Besides being
consistent with RSS-PSS and simpler, it would also improve compression
when compressing certificate chains (using algorithms like Brotli).

Cheers,
Brian

---

From: Russ Housley <[email-masked]>
Date: Tue, 7 Jun 2016 18:00:38 -0400

I think we have two choices, neither of them is in draft-curdle-pkix-00.

Either we define eight object identifiers for the named curves for use with id-ecPublicKey:

       id-Curve25519
       id-Curve448
       id-Curve25519ph
       id-Curve448ph
       id-ed25519
       id-ed25519ph
       id-ed448
       id-ed448ph

or we define eight object identifiers that are used as algorithm identifiers:

       id-ecPublicKeyCurve25519
       id-ecPublicKeyCurve448
       id-ecPublicKeyCurve25519ph
       id-ecPublicKeyCurve448ph
       id-ecPublicKeyED25519
       id-ecPublicKeyED25519ph
       id-ecPublicKeyED448
       id-ecPublicKeyED448ph

I can live with either one, but I would like to see us choose soon.

Russ

On Jun 7, 2016, at 4:58 PM, Daniel Migault <[email-masked]> wrote:

> Hi, 
> 
> Do we have some consensus that having top-level OID would be better ? Please provide your opinion and let the WG know your thoughts so the document can be moved forward. 
> 
> BR, 
> Daniel
> 
> On Thu, May 19, 2016 at 10:41 AM, David Benjamin <[email-masked]> wrote:
> On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos <[email-masked]> wrote:
> It's certainly possible I'm misunderstanding what section 3 was for. I was kind of confused why there were two encodings. I was getting id-ecPublicKey from:
> 
> """
>    which contains the namedCurve CHOICE.  Here we introduce two [I think this should be four] new OIDs

---

From: David Benjamin <[email-masked]>
Date: Tue, 07 Jun 2016 22:52:11 +0000

> Either we define eight object identifiers for the named curves for use

Were you thinking that id-Curve25519 refer to anything using the curve or
specifically the Diffie-Hellman primitive? If the latter, I would suggest
X25519 (for consistency with RFC 7748) and dropping the "ph" ones since
those are only in EdDSA. If the former, it seems redundant with the EdDSA
OIDs below.

       id-ed25519
>        id-ecPublicKeyCurve25519ph

Nit: I would suggest dropping the ecPublicKey prefix and s/ED/Ed/ to be
consistent with the usual styling. Also the same "X" vs "Curve" and "ph"
comments above. So:

id-X25519
id-X448
id-Ed25519
id-Ed25519ph
id-Ed448
id-Ed448ph

(Or maybe all lowercase? Between id-rsaEncryption and id-RSASSA-PSS, I'm
unclear on whether OIDs are supposed to be lowercase. Anyway...)

> I can live with either one, but I would like to see us choose soon.

(I obviously have a preference, but I've argued for it elsewhere. :-) )

>> It's certainly possible I'm misunderstanding what section 3 was for. I
>> was kind of confused why there were two encodings. I was
>> getting id-ecPublicKey from:
>>
>> """

---

From: Russ Housley <[email-masked]>
Date: Tue, 7 Jun 2016 18:00:38 -0400

id-Curve25519
       id-Curve448
       id-Curve25519ph
       id-Curve448ph
       id-ed25519
       id-ed25519ph
       id-ed448
       id-ed448ph

       id-ecPublicKeyCurve25519
       id-ecPublicKeyCurve448

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 7 Jun 2016 19:20:05 -0400

id-Curve25519
       id-Curve448
       id-Curve25519ph
       id-Curve448ph
       id-ed25519
       id-ed25519ph
       id-ed448
       id-ed448ph

       id-ecPublicKeyCurve25519
       id-ecPublicKeyCurve448

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 8 Jun 2016 09:57:37 -0400

All good suggestions.  Thanks.

Russ

On Jun 7, 2016, at 6:52 PM, David Benjamin <[email-masked]> wrote:

> Were you thinking that id-Curve25519 refer to anything using the curve or specifically the Diffie-Hellman primitive? If the latter, I would suggest X25519 (for consistency with RFC 7748) and dropping the "ph" ones since those are only in EdDSA. If the former, it seems redundant with the EdDSA OIDs below.
> 
>        id-ed25519
>        id-ed25519ph
>        id-ed448
>        id-ed448ph
> 
> Nit: I would suggest dropping the ecPublicKey prefix and s/ED/Ed/ to be consistent with the usual styling. Also the same "X" vs "Curve" and "ph" comments above. So:
> 
> id-X25519
> id-X448
> id-Ed25519
> id-Ed25519ph
> id-Ed448
> id-Ed448ph
> 
> (Or maybe all lowercase? Between id-rsaEncryption and id-RSASSA-PSS, I'm unclear on whether OIDs are supposed to be lowercase. Anyway...)
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 8 Jun 2016 15:34:34 -0400

Hi,

Thank you Russ and David for the feed backs and clarifications. So my
understanding from this thread is that their is a need for IODs to qualify
the key and the signature, that is defining how to use the key or
check/generate the signature. In other words, the usage of the key. Curves
do not seem sufficient as the same curve may be used in different ways. As
a result, my understanding is that defining the usage which includes the
curve is preferable. The usage is defined by the algorithm and the
following IODs:

id-X25519
id-X448
id-Ed25519
id-Ed25519ph
id-Ed448
id-Ed448ph

If I am not correct, please correct me. Otherwise, I would like to see by
the end of the week:
 A) if anyone has a better alternative than using the following OIDs to
define the algorithms.
 B) if anyone is fine with this alternative
 C) if anyone is opposed with this alternative
 D) if anyone has better names.

BR,
Daniel

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 10 Jun 2016 03:16:38 -0400 (EDT)

I support this.

----- Original Message -----
Hi,

BR,
Daniel

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 19 Jun 2016 21:11:22 -0700

The one downside that this approach has is that it makes negotiation either
much easier or a lot harder depending on what you are trying to negotiate.

It makes it easier to agree on a curve, as the curve is part of the system
and now does not need to be negotiated separately.  On the other hand, one
cannot say that one is willing to take any curve that is supported for
either ECDH, EdDSA or EdDSAph depending on what type of algorithm is
desired.

This is going to be complicated for ECDH given that one is going to
potentially need to negotiate the new curves and the old curves at the same
time in different methods.  

I am not really in favor of using top level OIDs for all of the different
combinations of keys and algorithms.

Jim

> -----Original Message-----
> From: Curdle [mailto:[email-masked]] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, June 10, 2016 12:17 AM
> To: Daniel Migault <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal
> 
> I support this.
> 
> >> > exposing it makes parsing more complex, and it increases the risk
> >> > of reusing keys between related algorithms. We can get the best of
> >> > both worlds by separating entry-points and sharing internals.
> >>
> > was kind of confused why there were two encodings. I was getting
> > id-ecPublicKey
> > from:
> >
> > """
> >> simpler to use a common OID and move it up. Unlike the NIST curves
> >> the constructions we have under the eddsa OID umbrella are quite
distinct.
> >>
> >> I was concerned about future extensibility and the fact that
> >> pureEdDSA and PrehashedEdDSA could be with separate algorithm OIDs,
> >> but after thinking it further, I think what you suggest is much
> >> neater, as having a single OID to identify scheme+curve will also
> >> restrict private keys to a single purpose which is a good thing.
> >>
> >> +1
> >>
> >> regards,
> >> Nikos
> >>
> >>

---

From: David Benjamin <[email-masked]>
Date: Mon, 20 Jun 2016 22:02:00 +0000

> either ECDH, EdDSA or EdDSAph depending on what type of algorithm is

When were you thinking one would wish to do that? My claim is this is not a
thing that makes sense to advertise.

What does it mean to advertise EdDSA in your algorithms list and P-256
(because you're willing to do P-256 + ECDH) and Curve25519 in your curves
list? EdDSA for P-256 isn't defined. EdDSA also isn't parameterized on
curve alone. It has a hash function we pair with it. That second choice
being implicit is odd. (And problematic if, say, someone defines
Ed25519-SHA3 := EdDSA(curve25519, SHA3-512) or so.)

This is the same problem TLS 1.3 had. TLS 1.2 negotiated curves and
algorithms separately, and we switched it to a scheme much closer to the
proposal. The old curve list is used for key exchange alone, and the
signature algorithms list recast to specify only unparameterized algorithms
like rsa_pss_sha256, ecdsa_p256_sha256, and ed25519.

Forcing X25519, Ed25519, and Ed25519ph into the same "curve" also means
SPKIs don't say which algorithm they're for. If you're thinking
id-ecPublicKey, we'd use the key usage. But X25519 and Ed25519's public key
formats aren't even compatible. Ed25519's curve is equivalent to X25519's,
but it's not the same.

Ed25519 and Ed25519ph are more comparable, but key reuse between the two
breaks the algorithms. (A signature for M in Ed25519ph will forge a
signature for SHA-512(M) in Ed25519 if keys are mixed.) They also do not
have the same type signature. Ed25519 is a single-shot function while
Ed25519ph is an Init/Update/Final triple.

> time in different methods.

I could imagine we do id-ecPublicKey with separate x25519/ed25519/ed25519ph
namedCurve values which would avoid this concern, but it's nothing like
id-ecPublicKey. The three named "curves" are nothing like existing curves.
Existing curves are usable with ECDH or ECDSA with any hash. They come with
the X9.62 serialization and multiple point format business. They decide on
algorithm via key usage extension. These new ones are straight-forward
functions on byte strings that do just one algorithm, as the rest of things
should have been designed.

Yes, it is a break from the old world, but I think one that is warranted. I
would rather we make the clean break and avoid these historical mistakes
now rather than perpetuate them further. One already must account for
future algorithms that don't have "elliptic curve" in the name anyway.

---

From: Daniel Migault <[email-masked]>
Date: Thu, 23 Jun 2016 17:21:08 +0000

Hi all,

We currently do not have consensus whether we should be using top level OID or not. This is an important issue, and we would like to find a consensus as soon as possible, so please provide your opinion by next week.

BR,
Daniel

From: David Benjamin [mailto:[email-masked]]
Sent: Monday, June 20, 2016 6:02 PM
To: Jim Schaad; Daniel Migault
Cc: [email-masked]
Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal

On Mon, Jun 20, 2016 at 12:11 AM Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
The one downside that this approach has is that it makes negotiation either
much easier or a lot harder depending on what you are trying to negotiate.

When were you thinking one would wish to do that? My claim is this is not a thing that makes sense to advertise.

What does it mean to advertise EdDSA in your algorithms list and P-256 (because you're willing to do P-256 + ECDH) and Curve25519 in your curves list? EdDSA for P-256 isn't defined. EdDSA also isn't parameterized on curve alone. It has a hash function we pair with it. That second choice being implicit is odd. (And problematic if, say, someone defines Ed25519-SHA3 := EdDSA(curve25519, SHA3-512) or so.)

This is the same problem TLS 1.3 had. TLS 1.2 negotiated curves and algorithms separately, and we switched it to a scheme much closer to the proposal. The old curve list is used for key exchange alone, and the signature algorithms list recast to specify only unparameterized algorithms like rsa_pss_sha256, ecdsa_p256_sha256, and ed25519.

Forcing X25519, Ed25519, and Ed25519ph into the same "curve" also means SPKIs don't say which algorithm they're for. If you're thinking id-ecPublicKey, we'd use the key usage. But X25519 and Ed25519's public key formats aren't even compatible. Ed25519's curve is equivalent to X25519's, but it's not the same.

Ed25519 and Ed25519ph are more comparable, but key reuse between the two breaks the algorithms. (A signature for M in Ed25519ph will forge a signature for SHA-512(M) in Ed25519 if keys are mixed.) They also do not have the same type signature. Ed25519 is a single-shot function while Ed25519ph is an Init/Update/Final triple.

I could imagine we do id-ecPublicKey with separate x25519/ed25519/ed25519ph namedCurve values which would avoid this concern, but it's nothing like id-ecPublicKey. The three named "curves" are nothing like existing curves. Existing curves are usable with ECDH or ECDSA with any hash. They come with the X9.62 serialization and multiple point format business. They decide on algorithm via key usage extension. These new ones are straight-forward functions on byte strings that do just one algorithm, as the rest of things should have been designed.

Yes, it is a break from the old world, but I think one that is warranted. I would rather we make the clean break and avoid these historical mistakes now rather than perpetuate them further. One already must account for future algorithms that don't have "elliptic curve" in the name anyway.

Jim

> From: Curdle [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nikos
> Mavrogiannopoulos
> To: Daniel Migault <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> On Thu, May 19, 2016 at 10:41 AM, David Benjamin <[email-masked]<mailto:[email-masked]>>
> wrote:
>
> > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos
> > <[email-masked]<mailto:[email-masked]>>
> > wrote:
> >
distinct.
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Curdle mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 25 Jun 2016 23:49:25 -0400 (EDT)

David has basically convinced me of the superiority of the "one joint and
keep it well-oiled" philosophy (i.e., top-level OID) -- it's just too easy
for implementations to end up doing bad things when there are separate
parameters involved.

-Ben