3 PKIX Certificates
3.1 Introduction to Certificates
Certificates were originally defined by ITU (CCITT) and the latest definitions are described in ITU-T X.509 , but those definitions are (as always) not working.
Working certificate definitions for the Internet Community are found in the the PKIX RFCs RFC 3279 and RFC 3280 . The parsing of certificates in the Erlang/OTP SSL application is based on those RFCS.
Certificates are defined in terms of ASN.1 (ITU-T X.680 ). For an introduction to ASN.1 see ASN.1 Information Site.
3.2 PKIX Certificates
Here we base the PKIX certificate definitions in RFCs RFC 3279 and RFC 3280 . We however present the definitions according to
SSL-PKIX.asn1
module, which is an amelioration of thePKIX1Explicit88.asn1
,PKIX1Implicit88.asn1
, andPKIX1Algorithms88.asn1
modules. You find all these modules in thepkix
subdirectory of SSL.The Erlang terms that are returned by the functions
ssl:peercert/1/2
,ssl_pkix:decode_cert/1/2
, andssl_pkix:decode_cert_file/1/2
when the optionssl
is used in those functions, correspond the ASN.1 structures described in the sequel.3.2.1 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
, andvalidity
are quite obvious given the type definitions above, so we do not go further into their details.The
signatureAlgorithm
field ofCertificate
and thesignature
field ofTBSCertificate
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 ofCertificate
contains the value of the signature that the issuer computed by using the prescribed algorithm.The
issuer<c> and <c>subject
fields can contain many different types av data, and is therefore considered in a separate section. The same holds for theextensions
field. TheissuerUniqueID
and thesubjectUniqueID
fields are not considered further.3.2.2 TBSCertificate issuer and subject
Name ::= CHOICE { -- only one possibility for now -- rdnSequence RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName DistinguishedName ::= RDNSequence RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type ATTRIBUTE-TYPE-AND-VALUE-CLASS.&id ({SupportedAttributeTypeAndValues}), value ATTRIBUTE-TYPE-AND-VALUE-CLASS.&Type ({SupportedAttributeTypeAndValues}{@type}) } SupportedAttributeTypeAndValues ATTRIBUTE-TYPE-AND-VALUE-CLASS ::= { name | surname | givenName | initials | generationQualifier | commonName | localityName | stateOrProvinceName | organizationName | organizationalUnitName | title | dnQualifier | countryName | serialNumber | pseudonym | domainComponent | emailAddress }3.2.3 TBSCertificate extensions
The
extensions
field of aTBScertificate
is a sequence of typeExtension
, 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 toTRUE
must 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
andsubjectInfoAccess
, 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 of digitalSignature
,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 isssuer of the certificate. subjectInfoAccess How to access CA information of the subject of the certificate. PKIX Extensions