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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 May 2016 09:37:41 +0200

Hi,
 I've sent it already to Simon, but forwarding here for wider audience.
The current draft-ietf-curdle-pkix-00 uses two identifiers for Ed25519
curve.

When identifying the curve parameters in the public key, it is
identified by an enumerated field as in:
EdDSAParameters ::= ENUMERATED { ed25519   (1) ...

While when identifying the private key parameters the following object
identifier is used:
id-Curve25519   OBJECT IDENTIFIER ::= { 1.3.101.110 }

This there are two identifiers in the same draft for the same curve
parameters and that leads to more complexity in implementations.

Why not simply define EdDSAParameters ::= OBJECT IDENTIFIER, and use
the object identifier everywhere?

regards,
Nikos

---

From: David Benjamin <[email-masked]>
Date: Tue, 17 May 2016 14:20:35 +0000

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.

It's also more future-proof. Suppose SHA-512 broke. Maybe we'd define
Ed25519v2 using SHA3-512 instead. But Ed25519 and Ed25519v2 keys shouldn't
be mixed. Top-level algorithm OIDs makes extending this natural, while
trying to classify by curve, etc., means we need more moving parts.

This also aligns with how signatures work in TLS 1.3:
https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.1
(Though my advocating for this is not surprising. The TLS 1.3 change is my
fault. Though it seems to have had consensus.)

David

On Tue, May 17, 2016 at 3:37 AM Nikos Mavrogiannopoulos <[email-masked]>
wrote:

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 19 May 2016 10:40:24 +0200

On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote:
> 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.

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

---

From: David Benjamin <[email-masked]>
Date: Thu, 19 May 2016 14:41:28 +0000

> 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