Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch

From: Carl Wallace <[email-masked]>
Date: Wed, 11 Mar 2015 08:54:38 -0400

Inline…

From:  Mike Jones <[email-masked]>
Date:  Wednesday, March 11, 2015 at 1:16 AM
<snip>
Things I haven’t yet learned that I’d need to know to really write this
code:
> ·       How are the OIDs in the table at
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A
> represented as ASN.1 OID values?

OID encoding is a pain (but there are some free tools/source to help in this
regard). Fortunately for you, as Richard implicitly noted, you don’t need
the OIDs you reference when encoding a subject public key info. If you want
to encode them for some other purpose, this site from your employer has a
decent description of the OID encoding process:
https://msdn.microsoft.com/en-us/library/bb540809(v=vs.85).aspx

> ·       Are multiple OIDs sometimes present before the ASN.1 NULL, and if so,
> which algorithms require which sets of OIDs in what order?

Multiple OIDs are never present before the ASN.1 NULL here (nor is are the
parameters represented as ASN.1 NULL for other algorithms).  The structure
is AlgorithmIdentifier as defined below. If multiple OIDs were permitted the
algorithm field would be SEQUENCE or SET but it’s not.

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

> ·       Is there always the apparently unused zero byte in the key
> representation or if not, when is it present and absent?

The leading zero is present for any integer value with the high bit set,
which is the case for RSA keys being encoded here.

> ·       Is there always a leading zero byte in the RSA modulus or if not, when
> is it present and absent?

See above, except in this case the high bit is not set so no leading zero.

> ·       How are elliptic curve keys represented?

RFC 5912 is a fairly comprehensive resource for the structures you’ll need,
including public key and parameter structures for different algorithms.

---

From: Mike Jones <[email-masked]>
Date: Wed, 11 Mar 2015 16:46:48 +0000

Thanks for the commentary, Carl.  I was guessing that integers with the high bit set were prefixed by a zero byte, as you said.  That’s different than the zero byte (the 22nd byte in the attached RFC 7250 example) that comes before the ASN.1 INTEGER tag and length for the modulus, which I find to be more mysterious.  See below…

> ·        Is there always the apparently unused zero byte in the key representation or if not, when is it present and absent?

> The leading zero is present for any integer value with the high bit set, which is the case for RSA keys being encoded here.

This isn’t a leading zero of an integer – it’s a zero in the first byte of the bit field that holds the key value, which is followed by two ASN.1-encoded integers for the modulus and exponent.  Does anyone know why this zero is here?  And whether it is always there?

> ·        Is there always a leading zero byte in the RSA modulus or if not, when is it present and absent?

> See above, except in this case the high bit is not set so no leading zero.

As I surmised – thanks.

                                                            -- Mike