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

[Erwann Abalea <[e-mail]>]

Bonsoir,

> Le 22 juil. 2016 à 20:18, Ilari Liusvaara <[e-mail]> a écrit :
> 
> On Fri, Jul 22, 2016 at 06:00:11PM +0000, Erwann Abalea wrote:
>> 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.
> 
> 1.3.101.100 was used in the IETF -00 draft. I think I heard it got
> allocated for EdDSA.

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.

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

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.

>> id-EdXKeyAgreementAlgorithm OBJECT IDENTIFIER ::= { iso(1)
>> identified-organization(3) thawte(101) 102 }
> 
> 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
> as X.509 SPKI.

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.