> From: 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. > 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) > 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. > 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. > 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. > 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. > 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. > 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
