Dominique Quatravaux > Crypt-OpenSSL-CA-0.23 > Crypt::OpenSSL::CA::AlphabetSoup


Annotate this POD


New  5
Open  0
View/Report Bugs
Source   Latest Release: Crypt-OpenSSL-CA-0.24_01


Crypt::OpenSSL::CA::AlphabetSoup - A "PKIX" glossary



Abstract Syntax Notation one, a kind of ``binary XML'' used throughout the "X.*" standards trail.


See "DN"


Certification Authority, an RFC4210 concept that models the bunch of software and hardware that creates X509 certificates (see "STANDARDS" in Crypt::OpenSSL::CA::Resources). Unfortunately, the term CA is also used in other places, and in a very confusing fashion, to designate either


French name for "ITU-T"


See "DN"


Certificate Revocation List, the software equivalent of a state-issued list of stolen IDs. This list is signed by the "CA", providing a secure means to revoke a certificate. See also "OCSP".


Certificate Signing Request, a would-be certificate signed by the "EE" (as opposed to a ``regular'' certificate which is signed by the "CA"). There are two formats of CSR in use in "PKIX" today, "SPKAC" (used by all browsers of the Netscape family) and "PKCS#10" (used by the rest of the world).

Concretely, a Certificate Signing Request is a file in a particular format (typically "ASN.1") that contains the requestor's public key and various other informations, all covered by the requestor's signature. To ensure proof of possesion, some "CA"'s require that said signature also cover a randomly-generated challenge that the CA issues to the requestor; in this way, the CA guarantees that all CSRs it is going to process are fresh, thereby preventing a particular (and otherwise mostly harmless) kind of replay attack.


See "DN"


Distinguished Encoding Rules, also known as X690; one of the standardized ways of encoding "ASN.1" (meaning that yes, there are several of them, and as a matter of fact some deployments of ASN.1 require the parties to negotiate the binary data format that will be used on the wire prior to any actual communication, I guess it means that there are people out there who think life is way too long...) The special characteristic of DER compared to the other ASN.1 encodings is that it is distinguished, which for the rest of us actually means deterministic: given an ASN.1 abstract syntax tree, there are no two correct ways of encoding it into DER, which is a desirable property in crypto environments where changing even one bit in a datagram would make any digital signature invalid.


Distinguished Name, the rough "X.*" equivalent of an e-mail address. Distinguished Names are intended to read somewhat like a postal address, and consist (mostly) of a series of typed key=value pairs, for example (from RFC4514)

  CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
  O=OpenLDAP Foundation,ST=California,C=US

where CN means Common Name, OU means Organizational Unit, O means Organization, L means Locality, ST means State (or province) and C means country. Also seen in the wild are DC (Domain Component, a piece of a DNS domain e.g. dc=google,dc=com), and various longer forms or "OID"s.

Although the concept looks simple, the utter brain-deadness in the spec for transcribing DNs into "ASN.1" is embarassing evidence of something really wrong going on inside "ITU-T". (For more ramblings about this, search for IDX/PKI/DN in, click the source link and enjoy the POD. I have since repented, or so I would like you to believe.)


End Entity, an RFC4210 concept that models the user of a certificate / private key pair (see "STANDARDS" in Crypt::OpenSSL::CA::Resources)


Hardware Security Module, a device that strongholds cryptographic keys and can compute cryptographic algorithms using them without ever disclosing the keys themselves. There are HSMs of all prices and sizes, ranging from the ubiquitous smartcard or USB dongle to FIPS-certified, high-performance, redundant, multiple security domain, and usually outrageously expensive SCSI or PCI hardware.


Also known as CCITT, a standards body that deals with telcos.


See "DN"


See "DN"


Online Certificate Status Protocol, a network service that fixes the shortcomings of the "CRL" idea. Described in RFC2560, see "STANDARDS" in Crypt::OpenSSL::CA::Resources.


Object Identifier, the "ASN.1" equivalent of an X11 atom or Lisp symbol, in essence a globally-unique list of integers that points to a non-unique human name. For example is stateOrProvinceName, a "DN" attribute key; 1.2.840.113549.1.1.5 is sha1WithRSAEncryption, a cryptographic algorithm specification used in "X509" certificates as part of the "CA"'s signature; and is potCapacity, a variable susceptible of being probed over SNMP indicating "the number of units of beverage supported by this device (regardless of its current state)" (no kidding). You can even roll your own (for a modest fee)!

See "INTERNET SITES" in Crypt::OpenSSL::CA::Resources for more information about OIDs, including a couple of online databases that list them.


See "DN"


Privacy-enhanced Electronic Mail, an early attempt at deploying public-key cryptography over the Internet ( The file format of PEM, which consists of putting base64-encoded "DER" data between type markers such as -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, is still used by "PKIX" extensively.


Public Key Cryptography Standards, a group of cryptography standards published by RSA Security ( Some of them are referenced in "STANDARDS" in Crypt::OpenSSL::CA::Resources. An aspect of the PKCS series that is confusing at first is that not all of them deal with public-key cryptography proper - e.g. PKCS#11 is an API for smart cards.


The most widely used format of "CSR". In addition to the cryptographic fields (public key, signature, and proof-of-possession challenge), a PKCS#10 request contains X509-like fields such as a would-be subject "DN", certificate request flags, etc.


Public Key Infrastructure, a typically massive assortment of standards, software and hardware to put public key cryptosystem such as "RSA" to actual use in a computer system. "PKIX" and PGP are the two best known kinds of PKI; despite their relying on the same cryptographic algorithms, their trust models are very different, and their codebases are almost totally disjoint. Other, less-known PKI systems in actual use over the Internet today include SPKI and DNSSEC.


The "X509" "PKI", as opposed to the other PKIs such as PGP or SPKI. Described in (see "STANDARDS" in Crypt::OpenSSL::CA::Resources).


Registration Authority, an RFC4210 concept that models the operator of a PKI (typically a human) and her assorted software (see "STANDARDS" in Crypt::OpenSSL::CA::Resources)


Relative Distinguished Name, a path component of a "DN" of length 1, for example: OU=Yoyodyne.


Request For Comments, the Internet's most prominent standards body.


Rivest, Shamir and Aldeman, the names of the famous inventors of one of the earliest public-key cryptography algorithms, and still in wide use today. All state-of-the-art "PKI"s support RSA as of 2007, and many (including Crypt::OpenSSL::CA) support only that.


The standard for embedding cryptographic payloads from "PKIX" inside Internet e-mail, thereby providing security services such as authentication and confidentiality. This can be thought of as the equivalent of PGP's "ASCII armor" feature.


Signed Public Key and Challenge, a Netscape "CSR" format (see "STANDARDS" in Crypt::OpenSSL::CA::Resources).


See "DN"


The set of all telecom standards put forth by the "ITU-T" that pertain to ``data network and open system communication'' (see Standards of the X.* series are identified with numbers: the X400 series describes an electronic mail system (that existed long before the Internet's SMTP); X500 is a directory service (of which LDAP is heavily inspired). Unlike the fully open Internet "RFC"s, X.* standards are known (and loathed) for the complexity of their adoption process, the ensuing difficulty of accessing them in full including the various addenda and errata, and (historically) the expensive fees involved in doing so.


One of the "X.*" standards that describes cryptographic certificates. Like "ASN.1" before, this standard has been collated and transcribed into a set of "RFC"s, as explained in "STANDARDS" in Crypt::OpenSSL::CA::Resources; this made them much easier to use for the Internet world, both in terms of access fees and documentary quality.


Another name for "DER".

syntax highlighting: