Subject: Re: [Dcrup] ed25519 in DNS

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Mar 2018 12:52:55 +0000

Speaking as an individual.

There are few ASN1 fans in the IETF.  I think that, at the time, everyone thought it would be easier to have raw keys. It turns out that most of the toolkits being used make it easier to have ASN1-wrapped keys.  Therefore, even though it is kinda ugly, I would be in favor of ASN1-wrapping Ed25519 keys.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Mar 2018 10:31:11 -0400

OK so this is not the first time we have faced this issue with elliptic
curves. The financial services world defined elliptic curve public keys in
an entirely different matter.

I don't use ASN.1 schema, but here are the relevant lines from my code:

Class SubjectPublicKeyInfo
Algorithm AlgorithmIdentifier
SubjectPublicKey Bits

A SPKI is simply a tag and a string of bits. The encoding of that string of
bits is defined by the algorithm identifier. We already have algorithm
identifiers for the CFRG curves and those specify that the public key info
be encoded as specified in RFC 7748 and RFC 8032.

So if you take any library that implements the CFRG curves, mine included,
they will pack and unpack that format because it is the one specified in
the document. It is the one that you have to use when using the CFRG curves
with PKIX which is the only time I use ASN.1.

So that bit string is the bitstring that DNSSEC etc. MUST use for public
keys. Anything else will require additional code to be written. Anything
else will not be compatible with RFC 7748 and RFC 8032.

If you wanted to 'wrap the key in ASN.1', what you would do is to express
it in exactly the same form as in PKIX, i.e. a  SubjectPublicKeyInfo blob
combining the algorithm and the public key data and you would not specify
the algorithm id anywhere else.

We did not go down that path in JOSE, I can't imagine we will in XML Dig
Sig or anything else.  SubjectPublicKeyInfo blob handlers are not generally
exposed by PKIX implementations.

What we have here is a layering confusion. The typical crypto app is a
stack:

Layer 3: [Application stuff]
Layer 2: [PKIX Library]
Layer 1: [ASN.1 Library]

While PKIX implementations do include some ASN.1 handling code, they are
not usually generic ASN.1 processors and in particular, many can only parse
but not generate. Accessing layer 1 from layer 3 is a layer violation. It
is bad design to ask.

Parsing that ASN.1 fragment is indeed quite simple. But just you try
generating it in DER format and then tell me how easy it was. Even a list
of two items is actually very difficult to code correctly. I have written
many ASN.1 generators over the years and it is a week reading the docs
every time because they are awful and the generation of DER is perverse.

So no, I see absolutely no value in more ASN.1

* It is a layering violation.
* It is unnecessarily complex
* ASN.1 is poorly specified
* ASN.1 DER is even worse, it was an afterthought.
* The public key is encoded as a string of bits regardless

The only 'easy' way to get at this data is to either make use of a full
feature ASN.1 parser/generator library which means a run time overhead or
make use of what are typically undocumented calls in the PKIX support
libraries.

On Thu, Mar 29, 2018 at 8:52 AM, Salz, Rich <[email-masked]> wrote:

> There are few ASN1 fans in the IETF.  I think that, at the time, everyone
> thought it would be easier to have raw keys. It turns out that most of the
> toolkits being used make it easier to have ASN1-wrapped keys.  Therefore,
> even though it is kinda ugly, I would be in favor of ASN1-wrapping Ed25519
> keys.
>
>
>
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>
>