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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
