Inline… From: Mike Jones <[email protected]> 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.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
