Why do PKI ANS1 certs start with MII?
October 10th, 2012—–BEGIN CERTIFICATE—–
MII…snip…
—–END CERTIFICATE—–
Had fun working on an keystone bug this morning:
https://bugs.launchpad.net/keystone/+bug/1060389
Resulted in this change:
https://review.openstack.org/14309
But in the process we figured out why a PKI cert starts with MII by reading the ANS.1 spec.
Explained the reason in a comment in the patch committed, here’s the answer to $title without the keystone justification included:
thx to ayoung for sorting this out.
base64 decoded hex representation of MII is 3082
In [3]: binascii.hexlify(base64.b64decode(‘MII=’))
Out[3]: ’3082′according to: http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
pg4: For tags from 0 to 30 the first octet is the identfier
pg10: Hex 30 means sequence, followed by the length of that sequence.
pg5: Second octet is the length octet
first bit indicates short or long form, next 7 bits encode the number
of subsequent octets that make up the content length octets as an
unsigned binary int82 = 10000010 (first bit indicates long form)
0000010 = 2 octets (next 7 bits indicate octet count for content length)
so read the next 2 octets to get the length of the content.
October 11th, 2012 at 8:03 am
Thanks for writing it up.
I wonder if the length bytes get extended in chunks? It might be that you never see 83, but it goes 82, 84, 88, to align with integer sizes.
October 11th, 2012 at 9:14 am
I don’t think chunks are required.
The short form in the ANS.1 spec is equivalent to 30 81.
pg 5 of that doc states: “The short form can only be used if the number of octets in the contents octets is less than or equal to 127.”
Then at the end of the page it states: “In the long form, the length octets shall consist of an initial octet and one or more subsequent octets.”
Seems that if chunks were required that they would be included in the spec in that 8.3.1.5 section and that the short form would be at least 2 octets in length.