Are you sure there is an ExtendedKeyUsage indicating a "Certificate Sign" OID? Cert Sign AFAIK is only indicated in KeyUsage extension.
-Sandeep On Sat, Oct 1, 2011 at 9:24 AM, <jb-open...@wisemo.com> wrote: > On 01-10-2011 01:09, Dave Thompson wrote: > >> From: owner-openssl-users@openssl.**org <owner-openssl-us...@openssl.org>On >> Behalf Of >>> jb-open...@wisemo.com >>> Sent: Thursday, 29 September, 2011 18:46 >>> Because the attributes mentioned are only meaningful if covered by the >>> digital signature on the certificate, it cannot change in any format >>> conversion that keeps the certificate valid. >>> >>> The true format of certificates is binary BER encoded X.509. >>> >>> A .cer file is simply that structure directly. >>> >> Yes, or sometimes converted to PEM format. PEM is the binary >> represented in base64 plus dashes-BEGIN-x and dashes-END-x lines. >> It looks different in e.g. notepad but is fundamentally the same. >> > I was trying to keep it simple for the OP. In fact both .cer and .p7b > files can be Base64 encoded PEM style. PEM encoding a .p12/.pfx > file is less useful and might not even be allowed. > > > A P7b/PKCS#7 file is really a digitally signed message with >>> zero or more >>> attached signatures to help the recipient to check the signature, each >>> >> OYM attached *certificates* to help check the signature(s) >> > Sorry, typo, I was in a hurry when I wrote the message. > > certificate is the same X.509 BER structure, just placed inside a list >>> (SEQUENCE) inside a PKCS#7 structure (which is also BER encoded just >>> like the certificate). When using a P7b file to transport >>> certificates, >>> the message and signature fields are just left blank. >>> >>> A P12/PFX/PKCS#12 file is an encrypted file which stores various >>> certificates (the same X.509 BER structure as before), various >>> private keys and hints on where these items should be imported >>> into CryptoAPI and/or the old Netscape browser. >>> >>> Yes. >> >> So whatever the format, after loading and unpacking, you are left >>> with an X.509 structure which contains a few mandatory fields >>> (such as Subject, Issuer, Public Key, Private Key, Serial Number), >>> >> NOT PrivateKey! Also validityPeriod (start-time and end-time). >> BTW originally serialNumber often was truly serial (1, 2, 3, etc.) >> but for some time now it has been more common to make it >> a large unique (random or obscured) number. >> > Oops! big typo, of cause not the private key. "Such as" means there are > other fields not mentioned. > > and a lot of optional fields. One of those optional fields is a >>> list of "authenticated attributes". Each entry in that list has >>> >> Although included in the signed part, it is just called 'extensions'. >> 'authenticatedAttributes' and separate 'unauthenticatedAttributes' >> are fields in PKCS#7/CMS SignedData. >> > Sorry about that, Its hard to keep track of these subtle variations > without looking them up. > > a "type OID", a "critical" flag and some data. The entries may >>> be found in any order, your code needs to work whatever field >>> entry comes first, needs to ignore any entry whose "type OID" >>> you don't understand. >>> >>> You can ignore an extension you don't understand if it is >> non-critical; you should give an error if it is critical >> and you are actually relying on the cert for something. >> If just looking at a specific extension, as here, you >> don't need to even see other/unknown extensions. >> > I would have mentioned it, but for the OPs problem (deciding the > certificate > category), ignoring critical extensions is fine, so I removed that part > from > my post before hitting send. > > The optional "CA" occurs in this list as an entry with the "CA" >>> OID and a TRUE/FALSE value. So CA may be "not there", TRUE >>> or FALSE. >>> >>> Actually the extension is BasicConstraints; it contains >> CA: boolean and pathLen: OPTIONAL INTEGER. You can have: >> - omitted >> - CA=false >> - CA=true pathlen=unspecified >> - CA=true pathlen=somenumber >> For deciding 'CA or not' pathlen doesn't matter. >> > Oh, I forgot it was in the same Ext, this may affect any manual > parsing the OP might write. > > The optional "Key Usage" also occurs in this list as an entry >>> with the "Key Usage" OID and a value which is a list of OIDs >>> (one for each usage). So Key Usage mat be "not there", >>> "there" with the "certificate sign" OID listed in its value, >>> or "there" without the "certificate sign" OID in its value. >>> >>> You have two things conflated here. >> KeyUsage value is 9 predefined bits, including certSign. >> *Extended*KeyUsage value is a list of extensible OIDs. >> A cert can have either or both or neither. >> If you have both and they conflict, reliers should reject. >> > Oops, I really was a bit fast yesterday, so there are really 3 exts to > check for "can act as a CA at all": > > - BasicConstraints (look for CA:TRUE bit) > - KeyUsage (look for "certificate sign" bit being set) > - ExtendedKeyUsage (look for "certificate sign" OID in list) > > If any of these 3 are present, it is a CA (root or intermediate) > If none of these 3 are present, it is an end entity cert (CA issued or > toy). > > > I don't remember the function names to look at the >>> "authenticated attribute" list in OpenSSL and/or CryptoAPI, >>> but there should be functions that will let you check if the >>> list is there at all, and if so loop over all the entries, looking >>> at each to see if it is one you care about today. >>> >>> OpenSSL: AFAICS the functions never distinguish between extensions >> omitted entirely or present but empty (zero-length sequence), >> which should make no semantic difference to anyone ever. >> But unlike some other OpenSSL data structures these aren't >> hidden, so you can just look if you really care. >> >> Or you can just ask for a particular extension by OID >> or NID (which is OpenSSL's internal equivalent). >> >> And for this particular decision you can just call X509_check_ca >> which isn't in the manpage but is public in x509v3.h and appears >> to have been stable for years. It checks KU and BC.CA if present, >> or otherwise does some guessing that looks reasonable to me >> and even if you disagree you might use it as a starting point. >> >> On 29-09-2011 17:33, Harshvir Sidhu wrote: >>> >> <snip> >> >> >> > ______________________________**______________________________**__________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
