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

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 Jul 2016 14:36:42 +0300

On Sat, Jun 25, 2016 at 11:49:25PM -0400, Benjamin Kaduk wrote:
> 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.

Yeah, I think separate top-level OID seems the cleanest.

Furthermore, I listened to the lamps session today, and they agreeed
(strong consensus?) to send recommedation to CURDLE for that scheme.

And as for other questionable reasons, it would also be more compact
(assuming we can sub-OID the arcs, which I think we can): For using
+1 byte on OID, we can jettison parameters, which is -3 bytes, for
net of -2 bytes. :-)

More concretely:

Something like (in wire form for SubjectPublicKeyInfo.algorithm):
30 06 06 04 2B 65 64 01       Ed25519
30 06 06 04 2B 65 64 02       Ed25519ph
30 06 06 04 2B 65 64 03       X25519
30 06 06 04 2B 65 64 04       Ed448
30 06 06 04 2B 65 64 05       Ed448ph
30 06 06 04 2B 65 64 06       X448

And then for Certificate.signatureAlgorithm:
30 06 06 04 2B 65 64/65 01       Ed25519
30 06 06 04 2B 65 64/65 02       Ed25519ph
30 06 06 04 2B 65 64/65 04       Ed448
30 06 06 04 2B 65 64/65 05       Ed448ph

Where 64 or 65 is chosen based on if reusing the OID is OK (64)
or not (65).

Then e.g. Ed25519 SPKI would be encoded as:

30 2B 30 06 06 04 2B 65 64 01 03 21 00 <32 byte pubkey>

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Jul 2016 09:02:42 -0400

I think the same OID can be used in SubjectPublicKeyInfo.algorithm and Certificate.signatureAlgorithm and SignerInfo.signatureAlgorithm.

Russ

On Jul 22, 2016, at 7:36 AM, Ilari Liusvaara <[email-masked]> wrote:

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

---

From: David Benjamin <[email-masked]>
Date: Fri, 22 Jul 2016 14:07:49 +0000

+1

Also +1 to naming the ECDH/curve25519 OID as X25519 instead of Curve25519. I
believe the current terminology is for "curve25519" to mean the curve and
"X25519" to mean the DH function built on top of it. RFC 7748 also reflects
this naming:
https://www.ietf.org/mail-archive/web/cfrg/current/msg04996.html
https://tools.ietf.org/html/rfc7748

On Fri, Jul 22, 2016 at 3:02 PM Russ Housley <[email-masked]> wrote:

> I think the same OID can be used in SubjectPublicKeyInfo.algorithm and
> Certificate.signatureAlgorithm and SignerInfo.signatureAlgorithm.
>
> Russ
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 Jul 2016 20:46:21 +0300

> > Certificate.signatureAlgorithm and SignerInfo.signatureAlgorithm.

Oops, I missed that not only there was strong consensus in LAMPS to
recommend using separate top-level OIDs, they also recommended reuse
OIDs across those three uses.

> https://tools.ietf.org/html/rfc7748

So maybe something like this:
----------------------------------------------------------------------
The algorithm identifiers, to be used in algorithm field of
AlgorithmIdentifier (e.g. in SubjectPublicKeyInfo.algorithm,
Certificate.signatureAlgorithm, and SignerInfo.signatureAlgorithm) are:

PkixCfrgCurves OBJECT IDENTIFIER ::= { 1 3 101 100 }
id-Ed25519Signature OBJECT IDENTIFIER ::= { PkixCfrgCurves 1 }
id-Ed25519phSignature OBJECT IDENTIFIER ::= { PkixCfrgCurves 2 }
id-EcdhX25519 OBJECT IDENTIFIER ::= { PkixCfrgCurves 3 }
id-Ed448Signature OBJECT IDENTIFIER ::= { PkixCfrgCurves 4 }
id-Ed448phSignature OBJECT IDENTIFIER ::= { PkixCfrgCurves 5 }
id-EcdhX448 OBJECT IDENTIFIER ::= { PkixCfrgCurves 6 }

The parameters field MUST be absent (not NULL).

That is, in wire form, these AlgorithmIdenfiers (including
the SEQUENCE the in definition) are:

- 30 06 06 04 2B 65 64 01 for Ed25519
- 30 06 06 04 2B 65 64 02 for Ed25519ph
- 30 06 06 04 2B 65 64 03 for X25519
- 30 06 06 04 2B 65 64 04 for Ed448
- 30 06 06 04 2B 65 64 05 for Ed448ph
- 30 06 06 04 2B 65 64 06 for X448
----------------------------------------

The above probably needs some bikeshedding on the names and lots of
editorial fixups.

-Ilari

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 22 Jul 2016 18:00:11 +0000

Bonjour,

Hex dump of DER encoded thing isn’t nice.

Using ASN.1 and RFC5912 modules:

-- We need to contact Thawte Consulting, or Verisign, or whoever now owns the 1.3.101 OID arc, as OID hijacking is not allowed.

--
-- Public key types
--

id-EdDSAPublicKey OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 100 }
id-pk-Ed25519 OBJECT IDENTIFIER ::= { id-EdDSAPublicKey 1 }
id-pk-Ed25519ph OBJECT IDENTIFIER ::= { id-EdDSAPublicKey 2 }
id-pk-X25519 OBJECT IDENTIFIER ::= { id-EdDSAPublicKey 3 }
id-pk-Ed448 OBJECT IDENTIFIER ::= { id-EdDSAPublicKey 4 }
id-pk-Ed448ph OBJECT IDENTIFIER ::= { id-EdDSAPublicKey 5 }
id-pk-X448 OBJECT IDENTIFIER ::= { id-EdDSAPublicKey 6 }

 -- Encoding of the following public key types is defined in draft-irtf-cfrg-eddsa

pk-Ed25519 PUBLIC-KEY ::= {
  IDENTIFIER id-pk-Ed25519
  PARAMS TYPE NULL ARE absent
}

pk-Ed25519ph PUBLIC-KEY ::= {
  IDENTIFIER id-pk-Ed25519ph
  PARAMS TYPE NULL ARE absent
}

pk-X25519 PUBLIC-KEY ::= {
  IDENTIFIER id-pk-X25519
  PARAMS TYPE NULL ARE absent
}

pk-Ed448 PUBLIC-KEY ::= {
  IDENTIFIER id-pk-Ed448
  PARAMS TYPE NULL ARE absent
}

pk-Ed448ph PUBLIC-KEY ::= {
  IDENTIFIER id-pk-Ed448ph
  PARAMS TYPE NULL ARE absent
}

pk-X448 PUBLIC-KEY ::= {
  IDENTIFIER id-pk-X448
  PARAMS TYPE NULL ARE absent
}

PublicKeys PUBLIC-KEY ::= {
  -- previously defined public key algorithms
  | pk-Ed25519
  | pk-Ed25519ph
  | pk-X25519
  | pk-Ed448
  | pk-Ed448ph
  | pk-X448,
   ...
}

--
-- Signature algorithms
--

id-EdDSASignatureAlgorithm OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 101 }
-- IIUC, Russ Housley wants id-EdDSASignatureAlgorithm to be equal to id-EdDSAPublicKey. If it’s accepted, just change the last 101 above by a 100.

id-sa-Ed25519 OBJECT IDENTIFIER ::= { id-pk-EdDSASignatureAlgorithm 1 }
id-sa-Ed25519ph OBJECT IDENTIFIER ::= { id-EdDSASignatureAlgorithm 2 }
id-sa-Ed448 OBJECT IDENTIFIER ::= { id-EdDSASignatureAlgorithm 4 }
id-sa-Ed448ph OBJECT IDENTIFIER ::= { id-EdDSASignatureAlgorithm 5 }

-- Encoding of the signature value for the following signature algorithms is defined in draft-irtf-cfrg-eddsa

sa-Ed25519 SIGNATURE-ALGORITHM ::= {
  IDENTIFIER id-sa-Ed25519
  PARAMS TYPE NULL ARE absent
  PUBLIC-KEYS { pk-Ed25519 }
}

sa-Ed25519ph SIGNATURE-ALGORITHM ::= {
  IDENTIFIER id-sa-Ed25519ph
  PARAMS TYPE NULL ARE absent
  PUBLIC-KEYS { pk-Ed25519ph }
}

sa-Ed448 SIGNATURE-ALGORITHM ::= {
  IDENTIFIER id-sa-Ed448
  PARAMS TYPE NULL ARE absent
  PUBLIC-KEYS { pk-Ed448 }
}

sa-Ed448ph SIGNATURE-ALGORITHM ::= {
  IDENTIFIER id-sa-Ed448
  PARAMS TYPE NULL ARE absent
  PUBLIC-KEYS { pk-Ed448 }
}

SignatureAlgorithms SIGNATURE-ALGORITHM ::= {
  -- previously defined algorithms
  | sa-Ed25519
  | sa-Ed25519ph
  | sa-Ed448
  | sa-Ed448ph,
   ...
}

-- The following stuff is to be discussed, because there’s no use of X25519/448 keys for now, and they could be used in CMS (which isn’t PKIX).

--
-- Key agreement algorithms
--

id-EdXKeyAgreementAlgorithm OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 102 }

id-kaa-X25519 OBJECT IDENTIFIER ::= { id-pk-EdXKeyAgreementAlgorithm 1 }
id-kaa-X448 OBJECT IDENTIFIER ::= { id-EdXKeyAgreementAlgorithm 2 }

-- Encoding of crypto material for the following key agreement algorithms is defined in ???

kaa-X25519 KEY-AGREE ::= {
  IDENTIFIER id-kaa-X25519
  PARAMS TYPE NULL ARE absent
  PUBLIC-KEYS { pk-X25519 }
}

kaa-X448 KEY-AGREE ::= {
  IDENTIFIER id-kaa-X448
  PARAMS TYPE NULL ARE absent
  PUBLIC-KEYS { pk-X448 }
}

etc…

Cordialement,
Erwann Abalea

> Le 22 juil. 2016 à 13:36, Ilari Liusvaara <[email-masked]> a écrit :
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 Jul 2016 21:18:25 +0300

On Fri, Jul 22, 2016 at 06:00:11PM +0000, Erwann Abalea wrote:
> -- We need to contact Thawte Consulting, or Verisign, or whoever now
> owns the 1.3.101 OID arc, as OID hijacking is not allowed.

1.3.101.100 was used in the IETF -00 draft. I think I heard it got
allocated for EdDSA.
 
> id-EdDSASignatureAlgorithm OBJECT IDENTIFIER ::= { iso(1)
> identified-organization(3) thawte(101) 101 }

LAMPS recommendation was to use the same identifiers for signatures
and for keys.

> id-EdXKeyAgreementAlgorithm OBJECT IDENTIFIER ::= { iso(1)
> identified-organization(3) thawte(101) 102 }

I don't know what 1.3.101.102 is...

And besides, I have heard requests for a way of encoding X25519/X448 key
as X.509 SPKI.

-Ilari

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 22 Jul 2016 18:47:43 +0000

Bonsoir,

> Le 22 juil. 2016 à 20:18, Ilari Liusvaara <[email-masked]> a écrit :
> 

I haven’t found an authoritative source for this.
It’s not the first time, 1.3.6 belongs to DoD, but 1.3.6.1 was « self-allocated » in RFC1065.

> LAMPS recommendation was to use the same identifiers for signatures

That’s what I read later. You can either keep the name but reuse the OID, or remove the id-sa-* OIDs and change the sa-* algorithms to use the id-pk-Ed* OIDs.

> I don't know what 1.3.101.102 is…

That’s why there’s a commentary saying it needs to be discussed.
sa-Ed* make use of the pk-Ed* keys.
There’s no defined use of pk-X* keys, and they’re used for key agreement.

Since in the message I replied to, you proposed the following DER encoded sigalg:
30 06 06 04 2B 65 64/65 01       Ed25519
It seemed you wanted to use 1.3.101.101 for signature algorithms, so I expanded to 1.3.101.102 for key agreement algorithms.
But again, it’s a subject of discussion.

> And besides, I have heard requests for a way of encoding X25519/X448 key

The proposed module does just that…

It’s not mandatory to have an ASN.1 encoded value in the BIT STRING, but if you want to define one, feel free.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 Jul 2016 23:08:30 +0300

> It’s not the first time, 1.3.6 belongs to DoD, but 1.3.6.1 was « self-allocated » in RFC1065.

Didn't find anything authoritative, but I did find that Simon
switched to that OID (from much longer one) in persoal -02 draft.

> There’s no defined use of pk-X* keys, and they’re used for key agreement.

X.509 SPKI is used for more purposes than just X.509.

> But again, it’s a subject of discussion.

Back when I wrote that, I had missed that reuse is OK. And as I noted
then one should use those 64 values.

-Ilari

---

From: Rob Stradling <[email-masked]>
Date: Fri, 22 Jul 2016 21:54:16 +0100

On 22/07/16 21:08, Ilari Liusvaara wrote:
<snip>
> switched to that OID (from much longer one) in persoal -02 draft.

Symantec own Thawte.  I persuaded Symantec to offer to reserve/delegate 
a range of OIDs under 1.3.101 for EdDSA (see [1]).  Simon accepted the 
offer and provisionally allocated some OIDs (see [2]).

After further discussion (private email exchange between Simon, myself 
and Rick Andrews) it was decided to start the OID range at 1.3.101.100. 
This was for two reasons:
   1) to avoid clashing with any OIDs that Thawte Consulting might have 
allocated many years ago.  For example, I found evidence that 
1.3.101.1.4 and 1.3.101.1.4.1 had been allocated previously.
   2) because the printable ASCII for the DER encoding of these OIDs is, 
frankly, irresistable (see [3]).  :-)

It's not clear from my records if Rick reserved/delegated 
1.3.101.100...1.3.101.115 or 1.3.101.100..1.3.101.127 for EdDSA.  It 
won't be hard to clarify that with Symantec though.

Please don't use any 1.3.101.x.y OIDs until we've run out of 1.3.101.x 
OIDs.  There's no point wasting bytes.

[1] https://www.ietf.org/mail-archive/web/tls/current/msg16798.html

[2] https://www.ietf.org/mail-archive/web/tls/current/msg16835.html

[3] https://www.ietf.org/mail-archive/web/tls/current/msg16586.html

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 23 Jul 2016 00:02:03 +0300

On Fri, Jul 22, 2016 at 09:54:16PM +0100, Rob Stradling wrote:
> 1.3.101.100...1.3.101.115 or 1.3.101.100..1.3.101.127 for EdDSA.  It won't
> be hard to clarify that with Symantec though.

Well, we go by LAMPS recommedations, we need 6 OIDs. 

And good to know we have more than 2 OIDs....

> Please don't use any 1.3.101.x.y OIDs until we've run out of 1.3.101.x OIDs.
> There's no point wasting bytes.

:-)

-Ilari

---

From: Rob Stradling <[email-masked]>
Date: Fri, 22 Jul 2016 22:31:16 +0100

> Well, we go by LAMPS recommedations, we need 6 OIDs.

 From the raw minutes:
   "David Benjamin's proposal: 3 OIDs per curve: ECDH (25519 & 448);
    EdDSA (no PH); EdDSAph
   ...
   *** A hum to recommend David Benjamin's proposal was unanimously yes."

IIUC, this is what's required...

1.3.101.100 ECDH 25519
1.3.101.101 EdDSA (no PH) 25519
1.3.101.102 EdDSAph 25519
1.3.101.103 ECDH 448
1.3.101.104 EdDSA (no PH) 448
1.3.101.105 EdDSAph 448

Is that right?

<snip>

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 22 Jul 2016 23:57:53 +0000

Thanks for the reference to the authoritative OID allocation by Verisign, Rob.

That’s 1 octet less than expected.

In the ASN.1 module I proposed, id-EdDSASignatureAlgorithm and id-EdDSAPublicKey are to be removed, and the other defined OIDs to be replaced by:

id-pk-X25519 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 100 }
id-pk-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 101 }
id-pk-Ed25519ph OBJECT IDENTIFIER ::= { 1 3 101 102 }
id-pk-X448 OBJECT IDENTIFIER ::= { 1 3 101 103 }
id-pk-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 104 }
id-pk-Ed448ph OBJECT IDENTIFIER ::= { 1 3 101 105 }

The following may not be necessary.
id-sa-Ed25519 OBJECT IDENTIFIER ::= { id-pk-Ed25519 }
id-sa-Ed25519ph OBJECT IDENTIFIER ::= { id-pk-Ed25519ph }
id-sa-Ed448 OBJECT IDENTIFIER ::= { id-pk-Ed448 }
id-sa-Ed448ph OBJECT IDENTIFIER ::= { id-pk-Ed448ph }

Ditto for them.
id-kaa-X25519 OBJECT IDENTIFIER ::= { id-pk-X25519 }
id-kaa-X448 OBJECT IDENTIFIER ::= { id-pk-X448 }

Cordialement,
Erwann Abalea

> Le 22 juil. 2016 à 23:31, Rob Stradling <[email-masked]> a écrit :
>

---

From: Rob Stradling <[email-masked]>
Date: Sat, 23 Jul 2016 01:01:44 +0100

> id-pk-Ed448ph OBJECT IDENTIFIER ::= { 1 3 101 105 }

Thanks Erwann.  IINM, that exactly matches what I suggested.

<snip>

---

From: Jim Schaad <[email-masked]>
Date: Sat, 23 Jul 2016 13:57:03 -0400

> -----Original Message-----
> From: Curdle [mailto:[email-masked]] On Behalf Of Rob Stradling
> Sent: Friday, July 22, 2016 5:31 PM
> To: Ilari Liusvaara <[email-masked]>
> Cc: [email-masked]; Erwann Abalea <[email-masked]>; Daniel
> Migault <[email-masked]>
> Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal
> 

This is what I recommended in the presentation and expect to have
implemented.

I don't know that the numbers are right but the spirit is.

Jim