1. Internet X.509 Public Key Infrastructure (PKIX)

PKIX standardisation areas:

1. Profiles of X.509 Public Key Certificates and X.509 Certificate Revocation Lists (CRLs).
2. Management protocols.
3. Operational protocols.
4. Certificate policies and Certificate Practice Statements.
5. Time–stamping and data–certification/validation services.

1.1. PKI - Public-Key Infrastructure

A PKI is a set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke PKCs based on public–key cryptography.

A PKI consists of five types of components.

Type of component	Description
Certification Authorities (CAs)	to issue and revoke PKCs
Registration Authorities (RAs)	to vouch for the binding between public keys and certificate holder identities and other attributes
Certificate holders (end entities, EE)	to sign and encrypt digital documents
Clients (end entities, EE)	to validate digital signatures and their certification path from a known public key of a trusted CA
Repositories	to store and make available certificates and Certificate Revocation Lists (CRLs)

• PKI Management Requirements. The PKI management protocols ...
  1. must conform to the ISO/IEC 9594-8/ITU-T X.509 standards;
  2. must be possible to regularly update key pairs;
  3. use of confidentiality in PKI management protocols must be kept to a minimum
  4. must allow the use of different industry-standard cryptographic algorithms
  5. must not preclude the generation of key pairs by the end-entity concerned, by an RA, or by a CA.
  6. must support the publication of certificates by the end-entity concerned, by an RA, or by a CA.
  7. must support the production of Certificate Revocation Lists (CRLs)
  8. must be usable over a variety of "transport" mechanisms,
  9. authority for certification creation rests with the CA.
  10. A graceful, scheduled change-over from one non-compromised CA key pair to the next (CA key update) must be supported
  11. The functions of an RA may be carried out by the CA itself.
  12. The end entity must be ready to demonstrate possession of the private key value.

• PKI Management Operations

1.2. PMI - Privilege Management Infrastructure

PMI is the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke Attribute Certificates.

A PMI consists of five types of components.

Type of component	Description
Attribute Authorities (AAs)	to issue and revoke ACs (also called Attribute Certificate Issuer)
Attribute certificate verifier	to check the validity of an AC and then make use of the result
Attribute certificate holders (end entities, EEs)	to parse or process an AC
Clients (end entities, EEs)	to request an action for which authorisation checks are to be made
Repositories	to store and make available certificates and Certificate Revocation Lists (CRLs)

2. Certificate and Certificate Revocation List (CRL) Profile - RFC 3280

2.1. Certificate

     Certificate ::= SEQUENCE {
          tbsCertificate         TBSCertificate,
          signatureAlgorithm     AlgorithmIdentifier,
          signatureValue         BIT STRING 
          }

• tbsCertificate

      TBSCertificate ::= SEQUENCE {
            version           [0] EXPLICIT Version DEFAULT v1,
            serialNumber           CertificateSerialNumber,
            signature              AlgorithmIdentifier,
            issuer                 Name (DN),
            validity               Validity,
            subject                Name (DN),
            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] EXPLICIT Extensions OPTIONAL
                                   -- If present, version MUST be v3
            }
  

     Version  ::=   INTEGER   <  v1(0), v2(1), v3(2)  >
  
     CertificateSerialNumber    ::=  INTEGER
  
     Validity ::= SEQUENCE {
          notBefore       Time,
          notAfter        Time }
  
     SubjectPublicKeyInfo ::= SEQUENCE {
          algorithm              AlgorithmIdentifier,
          subjectPublicKey       BIT STRING }
  
     Extensions   ::=  SEQUENCE SIZE (1..MAX) OF Extension
  
     Extension ::=     SEQUENCE {
           extnID       OBJECT IDENTIFIER,
           critical     BOOLEAN DEFAULT FALSE,
           extnValue    OCTET STRING }

• signatureAlgorithm

      AlgorithmIdentifier  ::=  SEQUENCE {
           algorithm               OBJECT IDENTIFIER,
           parameters              ANY DEFINED BY algorithm OPTIONAL   }
  

• signatureValue

• Certificate Extensions (standard extensions)
  • Authority Key Identifier

          AuthorityKeyIdentifier ::= SEQUENCE {
              keyIdentifier             [0] KeyIdentifier           OPTIONAL,
              authorityCertIssuer       [1] GeneralNames            OPTIONAL,
              authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
      
          KeyIdentifier ::= OCTET STRING
    

  • Subject Key Identifier
  • Key Usage

          KeyUsage ::= BIT STRING {
                 digitalSignature        (0),
                 nonRepudiation          (1),
                 keyEncipherment         (2),
                 dataEncipherment        (3),
                 keyAgreement            (4),
                 keyCertSign             (5),
                 cRLSign                 (6),
                 encipherOnly            (7),
                 decipherOnly            (8) 
                 }
    

  • Certificate Policies
  • Policy Mappings

• Certificate Extensions (standard extensions) (cont'd)
  • Subject Alternative Name
  • Issuer Alternative Names
  • Subject Directory Attributes
  • Basic Constraints

          BasicConstraints ::= SEQUENCE {
               cA                      BOOLEAN DEFAULT FALSE,
               pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
    

  • Name Constraints
  • Policy Constraints
  • Extended Key Usage
  • CRL Distribution Points

          CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
      
          DistributionPoint ::= SEQUENCE {
              distributionPoint       [0]     DistributionPointName OPTIONAL,
              reasons                 [1]     ReasonFlags OPTIONAL,
              cRLIssuer               [2]     GeneralNames OPTIONAL }
      
          DistributionPointName ::= CHOICE {
              fullName                [0]     GeneralNames,
              nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
      
          ReasonFlags ::= BIT STRING {
               unused                  (0),
               keyCompromise           (1),
               cACompromise            (2),
               affiliationChanged      (3),
               superseded              (4),
               cessationOfOperation    (5),
               certificateHold         (6),
               privilegeWithdrawn      (7),
               aACompromise            (8) }
    

2.2. CRL (Certificate Revocation List)

  CertificateList ::= SEQUENCE {
       tbsCertList        TBSCertList,
       signatureAlgorithm AlgorithmIdentifier,
       signatureValue     BIT STRING }

• tbsCertList

      TBSCertList ::=    SEQUENCE  {
         version                   Version OPTIONAL,
                                         -- if present, MUST be v2
         signature                 AlgorithmIdentifier,
         issuer                    Name,
         thisUpdate                Time,
         nextUpdate                Time OPTIONAL,
         revokedCertificates       SEQUENCE OF SEQUENCE {
              userCertificate            CertificateSerialNumber,
              revocationDate             Time,
              crlEntryExtensions         Extensions OPTIONAL
                                               -- if present, MUST be v2
                                     } OPTIONAL,
         crlExtensions             [0] EXPLICIT Extensions OPTIONAL
                                               -- if present, MUST be v2
                                     }
  

• CRL Entry Extensions
  • Reason Code

          reasonCode ::= < CRLReason >
      
          CRLReason ::= ENUMERATED {
               unspecified             (0),
               keyCompromise           (1),
               cACompromise            (2),
               affiliationChanged      (3),
               superseded              (4),
               cessationOfOperation    (5),
               certificateHold         (6),
               removeFromCRL           (8),
               privilegeWithdrawn      (9),
               aACompromise           (10) }
    

2.3. Certification Path Validation

• Basic Certificate Processing
  • verify the basic certificate information. The certificate MUST satisfy each of the following:
    • The certificate was signed with the working_public_key_algorithm using the working_public_key and the working_public_key_parameters.
    • The certificate validity period includes the current time.
    • At the current time, the certificate is not revoked and is not on hold status. This may be determined by obtaining the appropriate CRL status information, or by out-of-band mechanisms.
    • The certificate issuer name is the working_issuer_name.

3. Online Certificate Status Protocol (OCSP) - RFC 2560

• An OCSP request contains the following data:
  • protocol version
  • service request
  • target certificate identifier
  • optional extensions which MAY be processed by the OCSP Responder
• Upon receipt of a request, an OCSP Responder determines if:
  1. the message is well formed
  2. the responder is configured to provide the requested service and
  3. the request contains the information needed by the responder

• All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following:
  • the CA who issued the certificate in question
  • a Trusted Responder whose public key is trusted by the requester
  • a CA Designated Responder (Authorized Responder) who holds a
  • specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA

• A definitive response message is composed of:
  • version of the response syntax
  • name of the responder
  • responses for each of the certificates in a request
  • optional extensions
  • signature algorithm OID
  • signature computed across hash of the response

• The response for each of the certificates in a request consists of
  • target certificate identifier
  • certificate status value
  • response validity interval
  • optional extensions

• This specification defines the following definitive response indicators for use in the certificate status value:
  • good
  • revoked
  • unknown

• Functional Requirements :
  • Certificate Content
  • Signed Response Acceptance Requirements
    1. The certificate identified in a received response corresponds to that which was identified in the corresponding request;
    2. The signature on the response is valid;
    3. The identity of the signer matches the intended recipient of the request.
    4. The signer is currently authorized to sign the response.
    5. The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent.
    6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time.

3.1. Request Syntax

     OCSPRequest     ::=   SEQUENCE {
         tbsRequest                TBSRequest,
         optionalSignature [0]     EXPLICIT Signature OPTIONAL }
  
     TBSRequest      ::=   SEQUENCE {
         version             [0]     EXPLICIT Version DEFAULT v1,
         requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
         requestList                 SEQUENCE OF Request,
         requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }
  
     Signature        ::=    SEQUENCE {
         signatureAlgorithm      AlgorithmIdentifier,
         signature               BIT STRING,
         certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
  
     Version          ::=            INTEGER  <   v1(0) >
  
     Request          ::=    SEQUENCE {
         reqCert                     CertID,
         singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }
  
     CertID           ::=    SEQUENCE {
         hashAlgorithm       AlgorithmIdentifier,
         issuerNameHash      OCTET STRING, -- Hash of Issuer’s DN
         issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
         serialNumber        CertificateSerialNumber }

3.2. OCSP Response

An OCSP response at a minimum consists of a responseStatus field indicating the processing status of the prior request. If the value of responseStatus is one of the error conditions, responseBytes are not set.

  OCSPResponse ::= SEQUENCE {
     responseStatus         OCSPResponseStatus,
     responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }
  
  OCSPResponseStatus ::= ENUMERATED {
      successful            (0), --Response has valid confirmations
      malformedRequest      (1), --Illegal confirmation request
      internalError         (2), --Internal error in issuer
      tryLater              (3), --Try again later
                                  --(4) is not used
      sigRequired           (5), --Must sign the request
      unauthorized          (6)   --Request unauthorized }

4. Certificate Policy and Certification Practices Framework - RFC 3647

4.1. Certificate policy (CP)

The X.509 standard defines a CP as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements". An X.509 Version 3 certificate may identify a specific applicable CP, which may be used by a relying party to decide whether or not to trust a certificate, associated public key, or any digital signatures verified using the public key for a particular purpose.

4.2. Certification Practice Statement (CPS)

The term certification practice statement (CPS) is defined as: "A statement of the practices which a certification authority employs in issuing certificates". A CPS establishes practices concerning lifecycle services in addition to issuance, such as certificate management (including publication and archiving), revocation, and renewal or re-keying.

• The main differences between CPs and CPSs can therefore be summarized as follows:
  1. A PKI uses a CP to establish requirements that state what participants within it must do. A single CA or organization can use a CPS to disclose how it meets the requirements of a CP or how it implements its practices and controls.
  2. A CP facilitates interoperation through cross-certification, unilateral certification, or other means. Therefore, it is intended to cover multiple CAs. By contrast, a CPS is a statement of a single CA or organization. Its purpose is not to facilitate interoperation (since doing so is the function of a CP).
  3. A CPS is generally more detailed than a CP and specifies how the CA meets the requirements specified in the one or more CPs under which it issues certificates.

4.3. Recommended CP or CPS outline

In order to comply with the RFC, the drafters of a compliant CP or CPS are strongly advised to adhere to the following outline:

1. INTRODUCTION
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
3. IDENTIFICATION AND AUTHENTICATION
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
6. TECHNICAL SECURITY CONTROLS
7. CERTIFICATE, CRL, AND OCSP PROFILES
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
9. OTHER BUSINESS AND LEGAL MATTERS

5. Time-Stamping Authorities (TSAs) - RFC 3628

5.1. Time-Stamp Token

1. The time-stamp token shall include an identifier for the time-stamp policy;
2. Each time-stamp token shall have a unique identifier;
3. The time values the TSU uses in the time-stamp token shall be traceable to at least one of the real time values distributed by a UTC(k) laboratory.
4. The time included in the time-stamp token shall be synchronized with UTC within the accuracy defined in this policy and, if present, within the accuracy defined in the time-stamp token itself;
5. If the time-stamp provider’s clock is detected as being out of the stated accuracy then time-stamp tokens shall not be issued.
6. The time-stamp token shall include a representation (e.g., hash value) of the datum being time-stamped as provided by the requestor;

7. The time-stamp token shall be signed using a key generated exclusively for this purpose.
8. The time-stamp token shall include:
   • where applicable, an identifier for the country in which the TSA is established;
   • an identifier for the TSA;
   • an identifier for the unit which issues the time-stamps.

5.2. Clock Synchronization with UTC

1. The calibration of the TSU clocks shall be maintained such that the clocks shall not be expected to drift outside the declared accuracy.
2. The TSU clocks shall be protected against threats which could result in an undetected change to the clock that takes it outside its calibration.
3. The TSA shall ensure that, if the time that would be indicated in a time-stamp token drifts or jumps out of synchronization with UTC, this will be detected.
4. The TSA shall ensure that clock synchronization is maintained when a leap second occurs as notified by the appropriate body. The change to take account of the leap second shall occur during the last minute of the day when the leap second is scheduled to occur. A record shall be maintained of the exact time (within the declared accuracy) when this change occurred.

5.3. Time-Stamp Protocol (TSP) - RFC 3161

• The TSA is REQUIRED:
  1. to use a trustworthy source of time.
  2. to include a trustworthy time value for each time-stamp token.
  3. to include a unique integer for each newly generated time-stamp token.
  4. to produce a time-stamp token upon receiving a valid request from the requester, when it is possible.
  5. to include within each time-stamp token an identifier to uniquely indicate the security policy under which the token was created.
  6. to only time-stamp a hash representation of the datum, i.e., a data imprint associated with a one-way collision resistant hash-function uniquely identified by an OID.
  7. to examine the OID of the one-way collision resistant hash-function and to verify that the hash value length is consistent with the hash algorithm.
  8. not to examine the imprint being time-stamped in any way (other than to check its length, as specified in the previous bullet).
  9. not to include any identification of the requesting entity in the time-stamp tokens.
  10. to sign each time-stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate.
  11. to include additional information in the time-stamp token, if asked by the requester using the extensions field, only for the extensions that are supported by the TSA. If this is not possible, the TSA SHALL respond with an error message.

5.4. Request Format

     TimeStampReq ::= SEQUENCE {
          version                      INTEGER < v1(1) >,
          messageImprint               MessageImprint,
            --a hash algorithm OID and the hash value of the data to be
            --time-stamped
          reqPolicy             TSAPolicyId               OPTIONAL,
          nonce                 INTEGER                   OPTIONAL,
          certReq               BOOLEAN                   DEFAULT FALSE,
          extensions            [0] IMPLICIT Extensions   OPTIONAL }
  
     MessageImprint ::= SEQUENCE   {
          hashAlgorithm               AlgorithmIdentifier,
          hashedMessage               OCTET STRING }

5.5. Response Format

     TimeStampResp ::= SEQUENCE {
          status                    PKIStatusInfo,
          timeStampToken            TimeStampToken   OPTIONAL  }
  
     PKIStatusInfo ::= SEQUENCE {
          status         PKIStatus,
          statusString PKIFreeText        OPTIONAL,
          failInfo       PKIFailureInfo   OPTIONAL }

     PKIStatus ::= INTEGER {
          granted                 (0),
          -- when the PKIStatus contains the value zero a TimeStampToken, as
             requested, is present.
          grantedWithMods         (1),
           -- when the PKIStatus contains the value one a TimeStampToken,
             with modifications, is present.
          rejection               (2),
          waiting                 (3),
          revocationWarning       (4),
           -- this message contains a warning that a revocation is
           -- imminent
          revocationNotification (5)
           -- notification that a revocation has occurred }

6. Public-Key Cryptography Standards (PKCS)