20032009 Ericsson AB. All Rights Reserved. The contents of this file are subject to the Erlang Public License, Version 1.1, (the "License"); you may not use this file except in compliance with the License. You should have received a copy of the Erlang Public License along with this software. If not, it can be retrieved online at http://www.erlang.org/. Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. PKIX Certificates UAB/F/P Peter Högfeldt 2003-06-09 A pkix_certs.xml
Introduction to Certificates

Certificates were originally defined by ITU (CCITT) and the latest definitions are described in , but those definitions are (as always) not working.

Working certificate definitions for the Internet Community are found in the the PKIX RFCs and . The parsing of certificates in the Erlang/OTP SSL application is based on those RFCS.

Certificates are defined in terms of ASN.1 (). For an introduction to ASN.1 see ASN.1 Information Site.

PKIX Certificates

Here we base the PKIX certificate definitions in RFCs and . We however present the definitions according to SSL-PKIX.asn1 module, which is an amelioration of the PKIX1Explicit88.asn1, PKIX1Implicit88.asn1, and PKIX1Algorithms88.asn1 modules. You find all these modules in the pkix subdirectory of SSL.

The Erlang terms that are returned by the functions ssl:peercert/1/2, ssl_pkix:decode_cert/1/2, and ssl_pkix:decode_cert_file/1/2 when the option ssl is used in those functions, correspond the ASN.1 structures described in the sequel.

Certificate and TBSCertificate Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm SignatureAlgorithm, signature BIT STRING } TBSCertificate ::= SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature SignatureAlgorithm, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] Extensions OPTIONAL -- If present, version MUST be v3 -- } Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore Time, notAfter Time } Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime }

The meaning of the fields version, serialNumber, and validity are quite obvious given the type definitions above, so we do not go further into their details.

The signatureAlgorithm field of Certificate and the signature field of TBSCertificate contain the name and parameters of the algorithm used for signing the certificate. The values of these two fields must be equal.

The signature field of Certificate contains the value of the signature that the issuer computed by using the prescribed algorithm.

The and subject]]> fields can contain many different types av data, and is therefore considered in a separate section. The same holds for the extensions field. The issuerUniqueID and the subjectUniqueID fields are not considered further.

TBSCertificate issuer and subject

TBSCertificate extensions

The extensions field of a TBScertificate is a sequence of type Extension, defined as follows,

Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue ANY }

Each extension has a unique object identifier. An extension with a critical value set to TRUEmust be recognised by the reader of a certificate, or else the certificate must be rejected.

Extensions are divided into two groups: standard extensions and internet certificate extensions. All extensions listed in the table that follows are standard extensions, except for authorityInfoAccess and subjectInfoAccess, which are internet extensions.

Depending on the object identifier the extnValue is parsed into an appropriate welldefined structure.

The following table shows the purpose of each extension, but does not specify the structure. To see the structure consult the PKIX1Implicit88.asn1 module.

authorityKeyIdentifier Used by to identify a certificate signed that has multiple signing keys. subjectKeyIdentifier Used to identify certificates that contain a public key. Must appear i CA certificates. keyUsage Defines the purpose of the certificate. Can be one or several ofdigitalSignature, nonRepudiation,keyEncipherment, dataEncipherment,keyAgreement, keyCertSign, cRLSign,encipherOnly, decipherOnly. privateKeyUsagePeriod Allows certificate issuer to provide a private key usage period to be short than the certificate usage period. certificatePolicies Contains one or more policy information terms indicating the policies under which the certificate has been issued. policyMappings Used i CA certificates. subjectAltName Allows additional identities to be bound the the subject. issuerAltName Allows additional identities to be bound the the issuer. subjectDirectoryAttributes Conveys identity attributes of the subject. basicConstraints Tells if the certificate holder is a CA or not. nameConstraints Used in CA certificates. policyConstraints Used in CA certificates. extKeyUsage Indicates for which purposed the public key may be used. cRLDistributionPoints Indicates how CRL (Certificate Revokation List) information is obtained. inhibitAnyPolicy Used i CA certificates. freshestCRL For CRLs. authorityInfoAccess How to access CA information of the issuer of the certificate. subjectInfoAccess How to access CA information of the subject of the certificate. PKIX Extensions