29 Oct 2021 17:53:22 UTC
- Distribution: Crypt-OpenSSL-CA
- Source (raw)
- Browse (raw)
- How to Contribute
- Issues (7)
- Testers (34 / 166 / 0)
- KwaliteeBus factor: 1
- % Coverage
- License: perl_5
- Perl: v5.8.0
- Activity24 month
- Download (145.24KB)
- MetaCPAN Explorer
- Subscribe to distribution
- This version
- Latest versionDOMQ Dominique Quatravaux
Crypt::OpenSSL::CA::AlphabetSoup - A "PKIX" glossary
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
the set of the cryptographic credentials (key and CA certificate) that the CA-as-a-computing-equipment needs to perform,
the whole security domain (more computers and programs) that it relies on and operates for (which typically includes one or several "RA"s),
the political domain (e.g. a company) that its signature vouches for;
or even the person that operates the CA, even though arguably there should be no such person in a well-designed "PKI"! (People operate the RA, but the CA can and should be fully automatic.)
French name for "ITU-T"
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.
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
CNmeans Common Name,
OUmeans Organizational Unit,
STmeans State (or province) and
Cmeans 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/DNin http://www.google.com/codesearch, 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. http://en.wikipedia.org/wiki/ITU-T
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 220.127.116.11 is
stateOrProvinceName, a "DN" attribute key; 1.2.840.113518.104.22.168 is
sha1WithRSAEncryption, a cryptographic algorithm specification used in "X509" certificates as part of the "CA"'s signature; and 22.214.171.124.126.96.36.199.2 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.
Privacy-enhanced Electronic Mail, an early attempt at deploying public-key cryptography over the Internet (http://en.wikipedia.org/wiki/Privacy-enhanced_Electronic_Mail). The file format of PEM, which consists of putting base64-encoded "DER" data between type markers such as
-----END CERTIFICATE-----, is still used by "PKIX" extensively.
Public Key Cryptography Standards, a group of cryptography standards published by RSA Security (http://en.wikipedia.org/wiki/PKCS). 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.
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:
Request For Comments, the Internet's most prominent standards body. http://www.ietf.org/rfc.html
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.
The set of all telecom standards put forth by the "ITU-T" that pertain to ``data network and open system communication'' (see http://en.wikipedia.org/wiki/ITU-T). 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".
Module Install Instructions
To install Crypt::OpenSSL::CA, copy and paste the appropriate command in to your terminal.
perl -MCPAN -e shell install Crypt::OpenSSL::CA
For more information on module installation, please visit the detailed CPAN module installation guide.