Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Crypt::OpenSSL::CA::AlUsereContributed PerlCrypt::OpenSSL::CA::AlphabetSoup(3)

       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

       o   the set of the cryptographic	credentials (key and CA	certificate)
	   that	the CA-as-a-computing-equipment	needs to perform,

       o   the whole security domain (more computers and programs) that	it
	   relies on and operates for (which typically includes	one or several

       o   the political domain	(e.g. a	company) that its signature vouches

       o   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"

       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

       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

       Another name for	"DER".

perl v5.24.1			  2017-07-0Crypt::OpenSSL::CA::AlphabetSoup(3)


Want to link to this manual page? Use this URL:

home | help