> From: owner-openssl-us...@openssl.org On Behalf Of carlyo...@keycomm.co.uk > Sent: Tuesday, 03 April, 2012 09:35
> >On Tue 03/04/12 2:21 PM , Balamurugan rajan > balamurugan....@gmail.com sent: > >I want to need to read the Certiifcate Key usage and > identify the combination values to determine what > certificate is >that . so i need the Keyuage values of X509V3 > certificate > > > > That's a completely different thing! From my understandingm, > the key usage extension may exist as an ASN1_OCTET_STRING but > it has a structure defined in RFC5280 - > http://tools.ietf.org/html/rfc5280#appendix-A.1 > KeyUsage ::= BIT STRING { <snip> Yes but no. X509v3 extensions are defined as an OID plus an OCTET STRING which *contains* the DER encoding of the value whose type (within the encoding) depends on the OID, plus an optional BOOLEAN for critical. I believe they did it that way, instead of directly containing the value (in the already-DER TBS), because the full flexibility^Wmind-twisting complexity of ASN.1 to handle "y has type depending on x" wasn't developed yet in 1990-something. extnValue for KeyUsage is indeed a DER'ed BIT STRING. Aside: IINM this and other standard extensions (!) were actually defined by X.509 v3 and only 'profiled' by RFC 5280, but that does provide a convenient reference. > So, an octet / bit string that is a key usage extension > within a cert that has an example value of: > > 0106 > > Would be bit 8 (0100h) plus bit 2 (0004h) plus bit 1 (0002h): > decipherOnly > keyEncipherment > nonRepudation > But that's quite wrong. The DER encoding for BIT STRING is: 03 - tag nn - length, usually one octet 01-7F, could be multi-octet forms for extremely long bit strings not at issue here uu - num unused (padding) bits \ vv - octets containg bits, | value .. big-endian, padded to | octets vv octet with zero bits / This scheme allows additional bits to be added to a spec preserving existing encoded (and for certs signed) data. Thus your example with bits 1,2,8 would be 03 03 07 60 80 60 - has bit 1 and 2 set 80 - has bit 8 set, and 7 padding bits The OpenSSL in-memory structure representing a cert, struct x509_st aka typedef X509, in addition to the ASN.1 data, contains copied values of some extensions, including unsigned long ex_kusage; which contains either the first octet of bits, or the first two swapped (with 9 bits defined, it can never be more than two), so bit0 = digsign is at 0x80, bit7 = enconly is at 0x1, bit8 = deconly is at 0x8000; see x509v3.h (also x509.h). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
