Subject: [Curdle] Encoding Public Keys

From: Jim Schaad <[email-masked]>
Date: Fri, 12 Aug 2016 17:27:37 -0700

For the document draft-ietf-curdle-pkix, I have done something that is
different and I wanted to see what people's reactions to it are going to be.

When encoding a SubjectPublicKey, you end up with

   0 30   42: SEQUENCE {
   2 30    5:   SEQUENCE {
   4 06    3:     OBJECT IDENTIFIER '1 3 101 112'
            :     }
   9 03   33:   BIT STRING 0 unused bits
            :     19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B 96
            :     C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66 61
            :   }

Note that I have not done an ASN.1 wrapping on the key itself before putting
it into the BIT STRING.

Pro:  This ends up being two bytes shorter than if we did a wrapping of an
OCTET STRING around the key and then placed the result of that in the BIT
STRING

Con:  This is not what any other algorithm has ever done, as far as I know,
so there is a good chance that people are going to screw this up in their
implementations.

Comments on the approach are solicited.

Jim

---

From: David Benjamin <[email-masked]>
Date: Sat, 13 Aug 2016 02:06:39 +0000

+1

I believe this is what id-ecPublicKey does too, except that it's the X9.62
serialization rather than the EdDSA one, so there's precedent for this too.

David

On Fri, Aug 12, 2016 at 8:28 PM Jim Schaad <[email-masked]> wrote:

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 13 Aug 2016 11:31:32 +0300

> serialization rather than the EdDSA one, so there's precedent for this too.

Yes, id-ecPublicKey has non-ASN.1 stuff inside that BIT STRING.

-Ilari

---

From: Jim Schaad <[email-masked]>
Date: Sat, 13 Aug 2016 12:34:22 -0700

Sigh ....

I have now seen it written to be done both ways in two different documents.

RFC 5480 - Says that the OCTET STRING ASN.1 wrapper is not used.  I find the text that says this to be obscure and could have been clearer.
RFC 5753 - This is a slightly different context (CMS), but the structure in ASN.1 is identical and is intended to be the same thing that is used in a certificate.  In this case the ASN.1 OCTET STRING wrapper is used.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, August 13, 2016 1:32 AM
> To: David Benjamin <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [Curdle] Encoding Public Keys
> 
> > I believe this is what id-ecPublicKey does too, except that it's the
> > X9.62 serialization rather than the EdDSA one, so there's precedent for this
> too.
>

---

From: David Benjamin <[email-masked]>
Date: Sat, 13 Aug 2016 20:18:54 +0000

Oh lovely. At least for X.509 on the web, I believe everyone intereprets it
as RFC 5480, though I agree it is phrased kind of confusingly.

Do you know what existing CMS implementations do? Perhaps we want to errata
RFC 5753.

(Part of the problem I think is that SubjectPublicKeyInfo should have been
an OCTET STRING instead of a BIT STRING, but we're stuck with that. As a
BIT STRING everyone needs to spell out the same mapping from lowercase
octet string to upper case BIT STRING. Though it seems RFC 3279 doesn't
even spell it out and you've just got to know the mapping is the natural
one given BIT STRING's DER representation.)

David

On Sat, Aug 13, 2016 at 3:34 PM Jim Schaad <[email-masked]> wrote:

> RFC 5480 - Says that the OCTET STRING ASN.1 wrapper is not used.  I find
> the text that says this to be obscure and could have been clearer.
> RFC 5753 - This is a slightly different context (CMS), but the structure
> in ASN.1 is identical and is intended to be the same thing that is used in
> a certificate.  In this case the ASN.1 OCTET STRING wrapper is used.
>
> Jim
>
>

---

From: Jim Schaad <[email-masked]>
Date: Sat, 13 Aug 2016 14:36:51 -0700

I have just filed the errata on RFC 5753 based on what I understand the implementations of OpenSSL and BouncyCastle do.  Both of these implementations apparently do not include the OCTET STRING wrapper.  But at least I now know why it is that I thought there was a wrapper on this.

Jim

From: Curdle [mailto:[email-masked]] On Behalf Of David Benjamin
Sent: Saturday, August 13, 2016 1:19 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Curdle] Encoding Public Keys

Oh lovely. At least for X.509 on the web, I believe everyone intereprets it as RFC 5480, though I agree it is phrased kind of confusingly.

Do you know what existing CMS implementations do? Perhaps we want to errata RFC 5753.

(Part of the problem I think is that SubjectPublicKeyInfo should have been an OCTET STRING instead of a BIT STRING, but we're stuck with that. As a BIT STRING everyone needs to spell out the same mapping from lowercase octet string to upper case BIT STRING. Though it seems RFC 3279 doesn't even spell it out and you've just got to know the mapping is the natural one given BIT STRING's DER representation.)

David

On Sat, Aug 13, 2016 at 3:34 PM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Sigh ....

Jim

> From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ]
> To: David Benjamin <[email-masked] <mailto:[email-masked]> >
> Cc: Jim Schaad <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 14 Aug 2016 09:40:59 +0000

>Do you know what existing CMS implementations do? Perhaps we want to errata

That's a six-year-old document, if this is the first time someone has noticed
a problem then I'm guessing it's not exactly widely deployed, so a change
wouldn't really cause breakage.

Peter.