Mike, I did this in the context of the work on the raw public key document for TLS.
Using an ASN.1 parser makes sense since the SubjectPublicKeyInfo is not just a blog but an ASN.1 structure that looks differently depending on the type of keys encoding (ECC vs. RSA). My code was done as part of the TLS stack itself it is not as usable as a command line tool. You referenced https://tools.ietf.org/html/rfc7250#appendix-A and this was created by extracing the SubjectPublicKeyInfo field from a self-signed certificate that was created with the OpenSSL tools. Ciao Hannes On 03/11/2015 06:16 AM, Mike Jones wrote: > I’ve always loved learning new things, so I decided yesterday to try to > learn first-hand how to write code that emitted X.509 > SubjectPublicKeyInfo (SPKI) values from scratch. By “from scratch”, I > mean using development tools without built-in X.509 or ASN.1 support. > > > > I took this on because of Stephen’s suggestion > http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that > people could just hash the SPKI values to create a key thumbprint. > Given I’d helped create the JSON-based hash input described in > http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I wanted > to give his alternative suggestion a fair shake (and learn some new > things along the way). This admittedly stream-of-consciousness and > overly long message describes my expedition to date… > > > > Thus far, I’ve spent 5 hours trying to learn to do this. I spent about > the first two hours searching for examples of creating the bytes of > X.509 certificates or SubjectPublicKeyInfo values without using ASN.1 > and/or X.509 libraries. I failed. > > > > Next, I tried to read the authoritative reference for what’s in the SPKI > field – the X.509 spec. Unfortunately, > http://www.itu.int/rec/T-REC-X.509/en told me “This text was produced > through a joint activity with ISO and IEC. According to the agreement > with our partners, this document is only available through payment.” > Since most developers would stop at that point, I did too. > > > > After that, I changed tacks and tried to find examples of sample > certificates with commentary on what all the values mean – the kind of > info developers would want when coding this. I had better luck with > that. After about another hour of Web searching, I found this really > useful example: http://tools.ietf.org/html/rfc7250#appendix-A. I also > found this one: > http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html. Going > through them byte-by-byte enabled me to reverse engineer some of the > ASN.1 and X.509 constructs used. > > > > Things I learned by looking at these 1024-bit RSA public key > representations included: > > · ASN.1 uses byte-aligned Tag-Length-Value encodings. > > · The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER are > respectively 0x30, 0x06, 0x05, 0x03, and 0x02. > > · These Length values are encoded as follows: > > o 159 – 0x81 0x9f > > o 9 – 0x09 > > o 0 – 0x00 > > · The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a 0x86 > 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. > > · The OID is followed by an ASN.1 NULL - 0x05 0x00. > > · The RSA Key is represented as an encapsulated bit field. > > · There is an apparently unused zero byte (the 22^nd byte of the > SPKI field in the RFC 7250 example) as the first byte of this bit field. > > · The rest of the bit field contains concatenated representations > of the modulus and the exponent as ASN.1 INTEGERs. > > · The 1024 bit modulus is represented in 129 bytes, with the > first byte being zero. > > > > This brought me up to hour four. Next, I went looking for a 2048 bit > cert to learn from (especially since JWA requires 2048+ bit RSA keys). > I found http://fm4dd.com/openssl/certexamples.htm and chose > 2048b-rsa-example-cert.der, from which I also learned: > > · These length values are encoded as follows: > > o 290 – 0x82 0x01 0x22 > > o 257 – 0x82 0x01 0x01 > > · From this, I deduced (possibly incorrectly J) that if the high > bit of the first length byte is 0, the remaining 7 bits represent the > length, but if the high bit of the first length byte is 1, the remaining > 7 bits represent the number of bytes used to represent the actual > length. (Hence the use of 0x81 for representing values in the range > 128-255 and the use of 0x82 for representing values in the range 256-32767.) > > · Length values are represented in big-endian byte order. > > · The 2048 bit key representation also starts with an apparently > unused zero byte. > > · The 2048 bit modulus is represented by 257 bytes, with the > first byte being zero. > > > > 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? > > · Are multiple OIDs sometimes present before the ASN.1 NULL, and > if so, which algorithms require which sets of OIDs in what order? > > · Is there always the apparently unused zero byte in the key > representation or if not, when is it present and absent? > > · Is there always a leading zero byte in the RSA modulus or if > not, when is it present and absent? > > · How are elliptic curve keys represented? > > > > This brought me up to about the fifth hour of my investigation, and I > decided to stop and write up my findings to date. Highlighted versions > of the example certificate from RFC 7250 and the SPKI value from > fm4dd.com are attached, should any of you want to follow along with my > reverse engineering. Tags are yellow. Lengths are green. OIDs are > purple. The apparently unused byte is red. Key values are blue. > > > > I readily admit that I could have easily missed something while > searching. If someone can point me to self-contained descriptions of > this information, I’d love to see them! > > > > ==== CONCLUSIONS ==== > > > > 1. I think it would be a fine thing to do to write an RFC describing > the mapping between key values and their SPKI representations. This > could take the form of a cookbook with entries like “For a 2048 bit RSA > key using RSASSA with SHA-256, emit these bytes, filling in slots A and > B in the template with the 256 bites of the mantissa and the 3 bytes of > the exponent”. Based on my searching, I don’t think this information > exists anywhere in a self-contained form accessible to developers (but I > could be wrong, of course). I’m not going to personally do it, but if > any of you want go for it, have at it! > > > > 2. If my experience is representative, telling developers to just hash > the SPKI representation of a JWK won’t be very effective unless they > already have X.509 support. Most will probably give up well before the > 5 hours that I’ve invested to get this this partial understanding of > what I’d need to know. If my experience is representative, > draft-ietf-jose-jwk-thumbprint will be much easier to implement for > these developers. > > > > Trying to live in the shoes of developers, > > -- Mike > > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
