You could do a similar template thing to what I posted above, but with different values.
On Wed, Mar 11, 2015 at 11:16 AM, John Bradley <[email protected]> wrote: > How do you generate it from a raw key in JWK based on "crv", "kty" , "x" > and "y" ? > > > > > On Mar 11, 2015, at 3:05 PM, Hannes Tschofenig < > [email protected]> wrote: > > > > Just adding a bit more info after a chat with my co-worker Manuel (on > CC). > > > > If you use the OpenSSL tools then you can generate the > > SubjectPublicKeyInfo structure with the following commands: > > > >> openssl ecparam -genkey -name prime256v1 -out ec.key && openssl ec -in > > ec.key -pubout -outform der -out ec.pub > > > >> dumpasn1 ec.pub > > > > 0 89: SEQUENCE { > > 2 19: SEQUENCE { > > 4 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) > > 13 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) > > : } > > 23 66: BIT STRING > > : 04 58 74 31 8E DB 77 7C D3 AA 13 E0 81 D2 2C 0F > > : F1 CA 15 89 5B 50 F5 E2 5F AF 45 DC 3D 29 17 64 > > : B2 0F 1A BE DE A3 77 70 CB D2 0F B5 6B 5F 11 92 > > : C6 38 BE 6A F6 0B 2F 80 B7 AE 7E 4A 0A 33 C4 14 > > : AC > > : } > > > > Ciao > > Hannes > > > > On 03/11/2015 06:23 PM, Hannes Tschofenig wrote: > >> 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 > >>> > >> > >> > >> > >> _______________________________________________ > >> jose mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/jose > >> > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
