- Top CA - A CA that is at the top of a PKI hierarchy. Note: This        is often also called a "Root CA," since in data structures terms        and in graph theory, the node at the top of a tree is the        "root." However, to minimize confusion in this document, we        elect to call this node a "Top CA," and reserve "Root CA" where        there is a single CA directly trusted by the EE. Readers new to        PKIX should be aware that these terms are not used consistently        throughout the PKIX documents, as the Internet PKI profile        [2459bis] uses "Root CA" to refer to what this and other        documents call a "Top CA," and "most-trusted CA" to refer to        what this and other documents call a "Root CA."         1.3 History        The PKIX working group was formed in October of 1995 to develop    Internet standards necessary to support PKIs. The first work item was    a profile of the ITU-T Recommendation X.509 PKC [FORMAT]. X.509,    which is a widely accepted basis for a PKI, including data formats    and procedures related to distribution of public keys via PKCs    digitally signed by CAs. X.509 does not however include a profile to    specify the support requirements for many of the PKC data structure's    sub- fields, for any of the extensions, nor for certain data values.    The Internet PKI profile [FORMAT] went through many draft versions    before becoming an RFC. Other profiles have been developed in PKIX    for particular algorithms to make use of the Internet PKI Profile    [FORMAT]. There has been no sense of conflict between the authors    that developed these profiles as they are seen as complimentary. The    Internet PKI profile has been a draft standard for more than six  Arsenault, Turner                                                    5  Internet-Draft                PKIX Roadmap                  July 2002    months and is currently going through an update process to clarify    any inconsistencies and to bolster certain sections, see [2459bis].        In parallel with the profile development, work was undertaken to    develop the protocols necessary to manage PKI-related information    was. The first developed was the Certificate Management Protocol    (CMP). It defines a message protocol to initialize, certify, update,    and revoke PKI entities [CMP]. The demand for an enrollment protocol    and the desire to use PKCS-10 message format as the certificate    request syntax lead to the development of two different documents in    two different groups. The Certificate Request Syntax (CRS) draft was    developed in the SMIME WG which used PKCS-10 [PKCS10] as the    certification request message format. Certificate Request Message    Format [CRMF] draft was also developed but in the PKIX WG. It was to    define a simple enrollment protocol that would subsume both the CMP    and CRS enrollment protocols, but it did not use PKCS-10 as the    certificate request message format. Then the certificate management    message format document, was developed to define an extended set of    management messages that flow between the components of the Internet    PKI. Certificate Management Messages over CMS (CMC) was developed to    allow the use of an existing protocol (S/MIME) as a PKI management    protocol, without requiring the development of an entirely new    protocol such as CMP [CMC]. It also included [PKCS10] as the    certificate request syntax, which caused work on the CRS draft to    stop. Information from the certificate management message format    document was moved into [CMP] and [CMC] so work on the certificate    management message format document was discontinued. After some    operational experience with [CMP], two drafts, one for using HTTP as    the transport protocol and one for Transmission Control Protocol    (TCP), were written to solve problems encountered by implementors.    These drafts were merged into one draft Transport Protocols for CMP    [TPCMP]. [CMP] has been a draft standard for more than six months and    is currently undergoing revisions to document. The transport section    has been removed and will remain in [TPCMP].        Another long debated topic in the WG dealt with certificate    revocation. Numerous drafts have been developed to address different    issues related certificate revocations. CMP supports revocation    request, response, revocation announcement, and requests for CRL    messages. CMC defines revocation request, revocation response, and    requests for CRL messages, but uses CMS as the encapsulating    protocol. [OCSP] was developed to address concerns that not all    relying parties want to go through the process checking CRLs from    every CA in the certification path. It defines an on-line mechanism    to determine the status of a given certificate, which may provide    more timely revocation information than is possible with CRLs. The    Simple Certification Verification Protocol (SCVP) was produced to    allow relying parties to off-load all of their certification    verification to another entity [SCVP]. The WG was arguably split over    whether such a function should be supported and whether it should be    its own protocol or included in OCSP. In response, a draft defining    OCSP Extensions was produced to include the functions of SCVP. [OCSP]    has been a draft standard for more than six months and is in the  Arsenault, Turner                                                    6  Internet-Draft                PKIX Roadmap                  July 2002    process of being revised [OCSPv2]. To capture the work from the OCSP    Extensions, two drafts were developed: Delegated Path Validation    [DPV] and Delegated Path Discovery [DPD]. The WG recognizes an eed to    address online delegated path validation and delegated path    discovery. At least three candidates currently exist. There are:    OCSPv2, SCVP, and DVCS. Given this multiplicity, the WG undertook to    produce [DPREQ] in order to factilate selection from among these or    possibly others.        One other certificate status draft called Open CRL Distribution Point    (OCDP) was produced which documented two extensions: one to support    an alternative CRL partitioning mechanism to the CRL Distribution    Point mechanism documented in the Internet PKI Profile [FORMAT] and    one to support identifying other revocation sources available to    certificate-users. The work from this draft was subsumed by an ITU-T    | ISO/IEC Amendment to X.509, hence work on this draft was halted.        Development of the operational protocols has been slightly more    straightforward. Four documents for the Light Weight Directory Access    Protocol (LDAP) have been developed one for defining LDAPv2 as an    access protocol to repositories [PKI-LDAPv2]; two for storing PKI    information in an directory [SCHEMA] and [ADDSCHEMA]; and one for    LDAPv3 requirements for PKI [PKI-LDAPv3]. Using the File Transfer    Protocol (FTP) and the Hyper Text Transmission Protocol (HTTP) to    retrieve PKCs and CRLs from PKI repositories was documented in    [FTPHTTP]. Recognizing that LDAP directories are not the only    repository service, the working group draft a Repository Locator    Service [RLS] to make use of DNS SRV records to locate where and how    PKI information can be retrieved from a repository.        In late 1998 the PKIX charter was revised to include protocols for    time stamping and data certification services. [TSP] was developed to    define protocols required to interact with a Time Stamp Authority    (TSA) who asserts that a datum existed priot to a given time. [DVCS]    allows to verify and assert the validity of all signatures attached    to the signed document using all appropriate status information and    PKCs or to verify and assert the validity of one or more PKCs at the    specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating    mechanism (though in [TSP] request for a time stamp are not required    to use [CMS]). A draft for extending trust in tokens in time was    developed to use [DCVS] to maintain the trust in a token issued by a    non- repudiation Trusted Third Party (NR TTP) after the key initially    used to establish trust in the token expires; however, this draft has    expired. The [TRNRS] draft was developed to describe those features    of a service which processes signed documents that must be present in    order for that service to constitute a "technical non- repudiation"    service.        Around the same time, a work item for ACs, defined in [X.509], was    added. ACs are similar to PKCs, but they do not bind public keys to    identities rather they bind attributes to identities. The attributes    bound to the identity can represent anything, but are mostly used to    support rule-based and role-based access control decisions. Two  Arsenault, Turner                                                    7  Internet-Draft                PKIX Roadmap                  July 2002    drafts have since been developed: the Internet Attribute Certificates    Profile for Authorizations [AC] and the Limited Attribute Certificate    Acquisition Protocol [LAAP]. The first profiles the fields and    extensions of the AC and the second provides a deliberately limited    protocol to access a repository when LDAP is not appropriate.        Other drafts have been produced to address specific issues. [DHPOP]    was developed to define two mechanisms by which a signature can    produced using a Diffie-Hellman pair. This draft provides a mechanism    to use Diffie-Hellam key pairs to authenticate a PKCS-10    certification request. [REP] was developed during the revision to the    Internet PKI Profile [FORMAT] to separate the definitions of the    object identifiers and encoding rules for keys and digital signatures    in PKCs. The Qualified Certificates [QC] and Permanent Identifier    [PI] drafts were developed to address naming issues.        From the alphabet soup above, it is clear why this roadmap is    required.         2 PKI     2.1 Theory        At the heart of recent efforts to improve Internet security are a    group of security protocols such as Secure Multipurpose Internet Mail    Extensions (S/MIME), Transport Layer Security (TLS), and Internet    Protocol Security (IPSec). All of these protocols rely on public-key    cryptography to provide services such as confidentiality, data    integrity, data origin authentication, and non-repudiation. The    purpose of a PKI is to provide trusted and efficient key and public    key certificate management, thus enabling the use of authentication,    non-repudiation, and confidentiality.        Users of public key-based systems must be confident that, any time    they rely on a public key, the subject that they are communicating    with owns the associated private key, this applies whether an    encryption or digital signature mechanism is used. This confidence is    obtained through the use of PKCs, which are data structures that bind    public key values to subjects. The binding is achieved by having a    trusted CA verify the subject's identity and digitally sign each PKC.        A PKC has a limited valid lifetime, which is indicated in its signed    contents. Because a PKC's signature and timeliness can be    independently checked by a certificate-using client, PKCs can be    distributed via untrusted communications and server systems, and can    be cached in unsecured storage in certificate-using systems.        PKCs are used in the process of validating signed data. Specifics    vary according to which algorithm is used, but the general process    works as follows (Note: there is no specific order in which the    checks listed below must be made; implementors are free to implement    them in the most efficient way for their systems):  Arsenault, Turner                                                    8  Internet-Draft                PKIX Roadmap                  July 2002          - The recipient of signed data verifies that the claimed identity        of the user is in accordance with the identity contained in the        PKC;            - The recipient validates that no PKC in the path is revoked (e.g.,        by retrieving a suitably-current Certificate Revocation List        (CRL) or querying an on-line certificate status responder), and        that all PKCs are within their validity periods at the time the        data was signed;            - The recipient verifies that the data are not claimed to have any        values for which the PKC indicates that the signer is not        authorized;            - The recipient verifies that the data have not been altered since        signing, by using the public key in the PKC.            - If all of these checks pass, the recipient can accept that the        data was signed by the purported signer. The process for keys        used for encryption is similar.        Note: It is of course possible that the data was signed by someone    very different from the signer, if for example the purported signer's    private key was compromised. Security depends on all parts of the    certificate-using system, including but not limited to: physical    security of the place the computer resides; personnel security (i.e.,    the trustworthiness of the people who actually develop, install, run,    and maintain the system); the security provided by the operating    system on which the private key is used; and the security provided    the CA. A failure in any one of these areas can cause the entire    system security to fail. PKIX is limited in scope, however, and only    directly addresses issues related to the operation of the PKI    subsystem. For guidance in many of the other areas, see [POLPROC].         2.2 Architecture Model        A PKI is defined as:        The 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 [MISPC]:          - Certification Authorities (CAs) that issue and revoke PKCs;            - Organizational Registration Authorities (ORAs) that vouch for the        binding between public keys and certificate holder identities