Subject: Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 1 Feb 2008 12:12:37 +0100

A few comments.

(...)

>PKIX will pursue new work items in the PKI arena if working group 
>members express sufficient interest, and if approved by the cognizant 
>Security Area director. For example, certificate validation under X. 
>509 and PKIX standards calls for a relying party to use a trust 
>anchor as the start of a certificate path. 

This is not fully correct. Proposed change:

"For example, certificate validation under X. 509 and PKIX standards 
calls for a relying party to use *one or more* trust anchors and 
optional *additional conditions* as the start of a certificate path".

> Neither X.509 nor extant 
>PKIX standards define protocols for the management of trust anchors. 

This is untrue.

RFC 4210 "PKI Certificate Management Protocols" (CMP) defines data structures 
that allow to change a single trust anchor. The posting of these data structures 
which are certificates allow to change gracefully one trust anchor. These certificates 
may be placed in a directory and can be retrieved using any kind of protocol able 
to obtain ordinary certificates.

Page 9 :

      10. A graceful, scheduled change-over from one non-compromised CA
          key pair to the next (CA key update) must be supported (note
          that if the CA key is compromised, re-initialization must be
          performed for all entities in the domain of that CA). An end
          entity whose PSE contains the new CA public key (following a
          CA key update) must also be able to verify certificates
          verifiable using the old public key. End entities who directly
          trust the old CA key pair must also be able to verify
          certificates signed using the new CA private key.  (Required
          for situations where the old CA public key is "hardwired" into
          the end entity's cryptographic equipment).

Page 19:

4.4 Root CA key update

   This discussion only applies to CAs that are a root CA for some end
   entity.

   The basis of the procedure described here is that the CA protects its
   new public key using its previous private key and vice versa. Thus
   when a CA updates its key pair it must generate two extra
   cACertificate attribute values if certificates are made available
   using an X.500 directory (for a total of four:  OldWithOld;
   OldWithNew; NewWithOld; and NewWithNew).

   When a CA changes its key pair those entities who have acquired the
   old CA public key via "out-of-band" means are most affected. It is
   these end entities who will need access to the new CA public key
   protected with the old CA private key. However, they will only
   require this for a limited period (until they have acquired the new
   CA public key via the "out-of-band" mechanism). This will typically
   be easily achieved when these end entities' certificates expire.

   The data structure used to protect the new and old CA public keys is
   a standard certificate (which may also contain extensions). There are
   no new data structures required.

Proposed change:

"PKIX standards define protocols for the management of a single trust anchor, 
but not for the management of several trust anchors trusted under a single 
validation policy.

ETSI defines signature policies formats in "ETSI TR 102 272 V1.1.1 (2003-12)
ASN.1 format for signature policies".  ETSI also defines signature policies formats 
in "ETSI TR 102 038 V1.1.1 (2002-04) XML format for signature policies

Validation policies are superset of signature policies, but there exists no standard 
to manage validation policies".

>Existing mechanisms for managing trust anchors, e.g., in browsers, 
>are limited in functionality and non-standard. There is considerable 
>interest in the PKI community to define a standard model for trust 
>anchor management, and standard protocols to allow remote management. 
>Thus a future work item for PKIX is the definition of such protocols 
>and associated data models.

Proposed change:

"Existing mechanisms for managing trust anchors, e.g., in browsers, 
are limited in functionality and non-standard. There is considerable 
interest in the PKI community to define standard data structures and 
protocols to allow remote management of validation policies. 
Thus a future work item for PKIX is the definition of such data structures, 
protocols and associated data models".

>UPDATED PKIX Milestones

>Feb 2008 Update to CMC approved as PROPOSED Standard
>Mar 2008 RFC 3280bis approved as PROPOSED Standard
>Mar 2008 ECC Algorithms approved as PROPOSED Standard
>Mar 2008 TAM Problem Statement published as Informational
 October  2008 TAM Problem Statement published as Informational
>Jul 2008 TAM Protocols and Models published as PROPOSED Standard
 April  2009 TAM data structures and protocols as PROPOSED Standard

Denis

PS 1 : ETSI TSs and TRs are available free of charge at:
http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx

PS 2: Validation policies are defined in RFC 3379 and used in RFC 5055 (SCVP).

---

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 7 Feb 2008 11:22:40 +0100

A few additional comments.

>>PKIX standards define protocols for the management of trust anchors. 

RFC 3125 (issued in september 2001), which is an S-MIME document, defines 
a signature policy, which includes components for a validation policy. 
So there exists material, that could be re-used to address the narrower scope 
of a validation policy.

Some relevant text from RFC 3125 is copied below :

3.6.1  Certificate Requirements

   The certificateTrustTrees identifies a set of self signed
   certificates for the trust points used to start (or end) certificate
   path processing and the initial conditions for certificate path
   validation as defined RFC 2459 [7] section 4.  This ASN1 structure is
   used to define policy for validating the signing certificate, the
   TSA's certificate and attribute certificates.

CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
        trustpoint                              Certificate,
                               -- self-signed certificate
        pathLenConstraint       [0] PathLenConstraint   OPTIONAL,
        acceptablePolicySet     [1] AcceptablePolicySet OPTIONAL,
                                -- If not present "any policy"
        nameConstraints         [2] NameConstraints     OPTIONAL,
        policyConstraints       [3] PolicyConstraints   OPTIONAL }

   The trustPoint field gives the self signed certificate for the CA
   that is used as the trust point for the start of certificate path
   processing.

   The pathLenConstraint field gives the maximum number of CA
   certificates that may be in a certification path following the
   trustpoint.  A value of zero indicates that only the given trustpoint
   certificate and an end-entity certificate may be used.  If present,
   the pathLenConstraint field must be greater than or equal to zero.
   Where pathLenConstraint is not present, there is no limit to the
   allowed length of the certification path.

   PathLenConstraint    ::=   INTEGER (0..MAX)

   The acceptablePolicySet field identifies the initial set of
   certificate policies, any of which are acceptable under the signature
   policy.  AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

   CertPolicyId ::= OBJECT IDENTIFIER

   The nameConstraints field indicates a name space within which all
   subject names in subsequent certificates in a certification path must
   be located.  Restrictions may apply to the subject distinguished name
   or subject alternative names.  Restrictions apply only when the
   specified name form is present.  If no name of the type is in the
   certificate, the certificate is acceptable.

   Restrictions are defined in terms of permitted or excluded name
   subtrees.  Any name matching a restriction in the excludedSubtrees
   field is invalid regardless of information appearing in the
   permittedSubtrees.

NameConstraints ::= SEQUENCE {
          permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
          excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

     GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

     GeneralSubtree ::= SEQUENCE {
          base                    GeneralName,
          minimum         [0]     BaseDistance DEFAULT 0,
          maximum         [1]     BaseDistance OPTIONAL }

     BaseDistance ::= INTEGER (0..MAX)

   The policyConstraints extension constrains path processing in two
   ways. It can be used to prohibit policy mapping or require that each
   certificate in a path contain an acceptable policy identifier.

   The policyConstraints field, if present specifies requirement for
   explicit indication of the certificate policy and/or the constraints
   on policy mapping.

PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

   If the inhibitPolicyMapping field is present, the value indicates the
   number of additional certificates that may appear in the path
   (including the trustpoint's self certificate) before policy mapping
   is no longer permitted.  For example, a value of one indicates that
   policy mapping may be processed in certificates issued by the subject
   of this certificate, but not in additional certificates in the path.

   If the requireExplicitPolicy field is present, subsequent
   certificates must include an acceptable policy identifier.  The value
   of requireExplicitPolicy indicates the number of additional
   certificates that may appear in the path (including the trustpoint's
   self certificate) before an explicit policy is required.  An
   acceptable policy identifier is the identifier of a policy required
   by the user of the certification path or the identifier of a policy
   which has been declared equivalent through policy mapping.

3.6.2  Revocation Requirements

   The RevocRequirements field specifies minimum requirements for
   revocation information, obtained through CRLs and/or OCSP responses,
   to be used in checking the revocation status of certificates.  This
   ASN1 structure is used to define policy for validating the signing
   certificate, the TSA's certificate and attribute certificates.

CertRevReq ::= SEQUENCE {
        endCertRevReq   RevReq,
        caCerts     [0] RevReq
    }

   Certificate revocation requirements are specified in terms of checks
   required on:

      *  endCertRevReq: end certificates (i.e., the signers certificate,
         the attribute certificate or the time-stamping authority
         certificate).

      *  caCerts: CA certificates.

            RevReq ::= SEQUENCE  {
             enuRevReq  EnuRevReq,
             exRevReq    SignPolExtensions OPTIONAL}

   An authority certificate is certificate issued to an authority (e.g.,
   either to a certification authority or to an attribute authority
   (AA)).

   A Time-Stamping Authority (TSA) is a trusted third party that creates
   time-stamp tokens in order to indicate that a datum existed at a
   particular point in time.  See [TSP].

EnuRevReq  ::= ENUMERATED {
        clrCheck        (0),
                   --Checks must be made against current CRLs
                   -- (or authority revocation lists (ARL))
        ocspCheck       (1), -- The revocation status must be checked
                  -- using the Online Certificate Status Protocol
                  -- (OCSP),RFC 2450.
        bothCheck       (2),
                  -- Both CRL and OCSP checks must be carried out
        eitherCheck     (3),
                  -- At least one of CRL or OCSP checks must be
                  -- carried out
        noCheck         (4),
                  -- no check is mandated
        other           (5)
                  -- Other mechanism as defined by signature policy
                  -- extension
          }

   Revocation requirements are specified in terms of:

      *  clrCheck: Checks must be made against current CRLs (or
         authority revocation lists);
      *  ocspCheck: The revocation status must be checked using the
         Online Certificate Status Protocol (RFC 2450);
      *  bothCheck: Both OCSP and CRL checks must be carried out;
      *  eitherCheck: Either OCSP or CRL checks must be carried out;
      *  noCheck: No check is mandated.

Denis