with client systems or end users in another administrative domain.    Use of a cross-certificate issued from CA_1 to CA_2 allows user    Alice, who trusts CA_1, to accept a PKC used by Bob, which was    issued by CA_2. Cross-certificates can also be issued from one CA to    another CA in the same administrative domain, if required.        Cross-certificates can be issued in only one direction, or in both    directions, between two CA's. That is, just because CA_1 issues a    cross-certificate for CA_2, CA_2 does not have to issue a cross-    certificate for CA_1.         2.4.8 Revocation        When a PKC is issued, it is expected to be in use for its entire    validity period. However, various circumstances may cause a PKC to    become invalid prior to the expiration of the validity period. Such    circumstances include change of name, change of association between    subject and CA (e.g., an employee terminates employment with an    organization), and compromise or suspected compromise of the    corresponding private key. Under such circumstances, the CA needs to    revoke the PKC.        X.509 defines one method of PKC revocation. This method involves each    CA periodically issuing a signed data structure called a certificate    revocation list (CRL). A CRL is a list that identifies the    references of revoked PKCs. This list contains a date of issue and    is signed by a CA and made freely available in a public repository.    Each revoked PKC is identified in a CRL by its PKC serial number.    When a certificate-using system uses a PKC, that system not only    checks the PKC signature and validity but also acquires a suitably    recent CRL and checks that the PKC serial number is not on that CRL.    The meaning of "suitably recent" may vary with local policy, but it    usually means the most recently issued CRL. A CA issues a new CRL on    a regular periodic basis (e.g., hourly, daily, or weekly). CA's may  Arsenault, Turner                                                   14  Internet-Draft                PKIX Roadmap                  July 2002    also issue CRLs aperiodically. For example, if an important key is    deemed compromised, the CA may issue a new CRL to expedite    notification of that fact, even if the next CRL does not have to be    issued for some time. (A problem of aperiodic CRL issuance is that    end-entities may not know that a new CRL has been issued, and thus    may not retrieve it from a repository.)        An entry is added to the CRL as part of the next update following    notification of revocation. An entry may be removed from the CRL    after appearing on one regularly scheduled CRL issued beyond the    revoked PKC's validity period. Leaving the revoked PKC on the CRL for    this extra period allows for PKCs that are revoked prior to issuing a    new CRL and whose invalidity date falls before the CRL issuing time    to be accounted for. If the revoked PKC is not retained on the CRL    for this extra period then the possibility arises that a revoked PKC    may never appear on a CRL.        An advantage of the CRL revocation method is that CRLs may be    distributed by exactly the same means as PKCs themselves, namely, via    untrusted communications and server systems.        One limitation of the CRL revocation method, using untrusted    communications and servers, is that the time granularity of    revocation is limited to the CRL issue period. For example, if a    revocation is reported now, that revocation will not be reliably    notified to certificate-using systems until the next CRL is issued,    which may be up to one hour, one day, or one week depending on the    frequency that the CA issues CRLs.        As with the X.509 v3 PKC format, in order to facilitate interoperable    implementations from multiple vendors, the X.509 v2 CRL format needed    to be profiled for Internet use. This was done as part of the    Internet PKI Profile [FORMAT]. However, PKIX does not require CAs to    issue CRLs. On-line methods of revocation notification may be    applicable in some environments as an alternative to the X.509 CRL.    PKIX defines a few protocols that support on-line checking. [OCSP],    [DVCS], and [SCVP] all support on-line checking of the status of    PKCs.        On-line revocation checking may significantly reduce the latency    between a revocation report and the distribution of the information    to relying parties. Once the CA accepts the report as authentic and    valid, any query to the on-line service will correctly reflect the    PKC validation impacts of the revocation. However, these methods    impose new security requirements; the PKC validator must trust the    on-line validation service while the repository does not need to be    trusted.         2.4.9 Certificate & Revocation Notice Distribution & Publication        As alluded to in sections 2.1 and 2.5.8 above, the PKI is responsible    for the distribution of PKCs and PKC revocation notices (whether in  Arsenault, Turner                                                   15  Internet-Draft                PKIX Roadmap                  July 2002    CRL form or in some other form) in the system. "Distribution" of PKCs    includes transmission of the PKC to its owner, and may also include    publication of the PKC in a repository. "Distribution" of revocation    notices may involve posting CRLs in a repository, transmitting them    to end-entities, or forwarding them to on-line responders.         3 PMI     3.1 Theory        Many systems use the PKC to perform identity based access control    decisions (i.e., the identity may be used to support identity-based    access control decisions after the client proves that it has access    to the private key that corresponds to the public key contained in    the PKC). For many systems this is sufficient, but increasingly    systems are beginning to find that rule-based and role-based access    control is required. These forms of access control decisions require    additional information that is normally not included in a PKC,    because the lifetime of the information is much shorter than the    lifetime of the public-private key pair. To support binding this    information to a PKC the Attribute Certificate (AC) was defined in    ANSI and later incorporated into ITU-T Recommendation X.509. The AC    format allows any additional information to be bound to a PKC by    including, in a digitally signed data structure, a reference back to    one specific PKC or to multiple PKCs, useful when the subject has the    same identity in multiple PKCs. Additionally, the AC can be    constructed in such a way that it is only useful at one or more    particular targets (e.g., web server, mail host).        Users of a PMI must be confident that the identity purporting to    posses an attribute has the right to possess that attribute. This    confidence may be obtained through the use of PKCs or it may be    configured in the AC-using system. If PKCs are used the party making    the access control decision can determine "if the AC issuer is    trusted to issue ACs containing this attribute."        ACs are complicated by the fact that they can point to an identity    which may be in more than one PKC. If the RP has multiple    certification chains to chose from then it has to make the    determination as to which certification path to trust. Regardless,    before the RP uses the AC it must make sure that a path from the AC    back to its trust point is valid.         3.2 Architectural Model        A Privilege Management Infrastructure, or PMI, is defined as:        The set of hardware, software, people, policies and procedures needed    to create, manage, store, distribute, and revoke ACs.        A PMI consists of five types of components [AC]:  Arsenault, Turner                                                   16  Internet-Draft                PKIX Roadmap                  July 2002          - Attribute Authorities (AAs), or Attribute Certificate Issuer,        that issue and revoke ACs;            Note: AAs may implicitly revoke ACs by using very short validity      periods.            - Attribute Certificate Users that parses or processes an AC;            - Attribute Certificate Verifiers that check the validity of an AC        and then makes use of the result;            - Clients that request an action for which authorization checks are        to be made;            - Repositories that store and make available certificates and        Certificate Revocation Lists (CRLs).        Figure 2 is an example of the exchanges that may involve ACs.           +--------------+       |              |        Server Acquisition       |  AC issuer   +----------------------------+       |              |                            |       +--+-----------+                            |          |                                        |          | Client                                 |          | Acquisition                            |          |                                        |       +--+-----------+                         +--+------------+       |              |       AC "push"         |               |       |   Client     +-------------------------+    Server     |       |              | (part of app. protocol) |               |       +--+-----------+                         +--+------------+          |                                        |          | Client                                 | Server          | Lookup        +--------------+         | Lookup          |               |              |         |          +---------------+  Repository  +---------+                          |              |                          +--------------+                       Figure 2: AC Exchanges         3.3 Attribute Certificates        ANSI X.9 first published the Attribute Certificate format. It defined    the standard version 1 (v1) AC format. They later created a version 2    (v2) AC by modifying the owner field to point to either an identity    or a specific PKC and including an extension mechanism. In 1997 ITU-T    included it in [X.509].      Arsenault, Turner                                                   17  Internet-Draft                PKIX Roadmap                  July 2002    ANSI, ITU-T, and IETF have developed standard extensions and    attributes for use in the v2 ACs. Extensions can convey such    information as an audit identity that can be used to create an audit    trail, identity specific servers and services where the AC owner can    use their AC, point to a specific issuer's key, and indicate where to    get revocation information. The AC is generic enough to allow any    attribute to be conveyed in the data structure. Without limiting the    attributes and extensions that can be included in an AC it is very    difficult to develop interoperable implementations for Internet use.    It is the goal of PKIX to specify a profile for the Internet,    electronic mail, IPSec applications, etc. Environments with    additional requirements may build on this profile or replace it.        The [AC] profile constrains many of the options allowed in X.509. For    example, the AC chains, like their PKC brethren, are allowed by    X.509, but the AC profile recommends that they not be supported in to    simplify the implementation.         4 PKIX Documents        This section identifies the five different areas in which the PKIX    working group has developed documents. The first area involves    profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards    for the Internet. The second area involves operational protocols, in    which relying parties can obtain information such as PKCs or PKC    status. The third area covers management protocols, in which    different entities in the system exchange information needed for    proper management of the PKI. The fourth area provides information    about certificate policies and certificate practice statements,    covering the areas of PKI security not directly addressed in the rest    of PKIX. The fifth area deals with providing time stamping and data    certification services, which can be used to build such services as    non-repudiation.         4.1 Profiles        An X.509 v3 PKC is a very complex data structure. It consists of    basic information fields, plus a number of optional extensions. Many    of the fields and numerous extensions can take on a wide range of    options. This provides an enormous degree of flexibility, which    allows the X.509 v3 PKC format to be used with a wide range of    applications in a wide range of environments. Unfortunately, this