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

[David Benjamin <[e-mail]>]

On Mon, Jun 20, 2016 at 12:11 AM Jim Schaad <[e-mail]> 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.
>
> 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.
>

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.

 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 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.


> 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:[e-mail]] On Behalf Of Nikos
> > Mavrogiannopoulos
> > Sent: Friday, June 10, 2016 12:17 AM
> > To: Daniel Migault <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification
> proposal
> >
> > I support this.
> >
> > ----- Original Message -----
> > 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 <[e-mail]>
> > wrote:
> >
> > > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos
> > > <[e-mail]>
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/curdle
> > >
> > >
> >
> > _______________________________________________
> > Curdle mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/curdle
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>