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

["Denis Pinkas" <denis.pinkas@xxxxxxxx>]

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).