Subject: Changes in draft-ietf-pkix-new-part1-03

From: Steve Hanna <[email-masked]>
Date: Wed, 29 Nov 2000 10:34:45 -0500

Here is a list of potentially significant changes between
draft-ietf-pkix-new-part1-02.txt and draft-ietf-pkix-new-part1-03.txt.

A simple diff will not suffice to find these changes because
hyphenation was turned off between these versions (probably to avoid
confusion and/or ambiguities). This caused many paragraphs to change
without any truly significant differences. I have edited the output of
diff to remove insignificant changes (such as typographical
corrections) and add comments about what each change means (in my
view).

I hope that this will be helpful for others who are closely tracking the
changes to this document.

To summarize, new-part1-03 includes the following changes:

1)  Added recommendation that pseudonym attribute type be supported.
2)  Support for inhibit any-policy extension now required instead of
    recommended.
3)  Removed recommendation against the subject directory attributes
    extension.
4)  Added a new section describing the subject information access extension.
5)  Clarified that the relying party can supply constraints to the validation
    algorithm via "initial state variables". Not quite clear what those are.
6)  Removed the validity period of the public key from the set of inputs
    required by the algorithm, since it was never used in the algorithm.
7)  Clarified that features described as optional in early sections
    may be omitted from the validation algorithm.
8)  Removed the issuer unique identifier from the trust anchor information.
    It still appears one place in the algorithm, but clearly the intent was
    to remove it.
9)  Added new behavior in policy processing to generate a child node of depth
    i that has a valid_policy of ID-P if certificate i contains a policy
    mapping extension with an issuerDomainPolicy ID-P and no node of depth i
    in the valid_policy_tree has a valid_policy of ID-P but there is a node
    of depth i with a valid_policy of any-policy.
10) Recommended that if you want to have different parameters for different
    trust you should supply different inputs to the path validation
    procedure. Old recommendation was to place limitations in the self-signed
    certificates used as the trust anchors. But that isn't a great idea and
    constraints in the trust anchors are not processed anyway (according to
    the algorithm).
11) Added several minor clarifications relating to the CPS Pointer policy
    qualifier, policy mapping, email addresses, extended key usage, the OCSP
    AuthorityInformationAccess access descriptor, the most-trusted CA, and
    long serial numbers.

I am quite pleased with these changes. I will send a separate email with
specific comments on this draft, but overall I think that it's in very good
shape and I would support moving it to WG Last Call soon. Minor issues and
typos can be resolved during the WG Last Call.

Completing work on this draft and moving it promptly to Proposed Standard
status will benefit other IETF working groups, whose documents depend on RFC
2459 and therefore cannot progress to Draft Standard status until this
document does so. Rapid progress on this draft will also benefit the PKI and
PKIX communities as a whole, since it will provide a stable standard on which
products can be based.

-Steve

------

My comments begin with a #. Lines from the -02 draft begin with a <.
Lines from the -03 draft begin with a >.

# In section 4.1.2.2 (Serial number),
# Added a comment emphasizing the requirements for serialNumbers. Similar
# text already appeared in Appendix B (and still does), but this
# location is much more prominent.
<    certificate).
---
>    certificate).  CAs MUST force the serialNumber to be a non-negative
>    integer.
> 
>    Given the uniqueness requirements above serial numbers can be
>    expected to contain long integers. Certificate users MUST be able to
>    handle serialNumber values up to 20 octets. Conformant CAs MUST NOT
>    use serialNumber values longer than 20 octets.
> 
>    Note: Non-conforming CAs may issue certificates with serial numbers
>    that are negative, or zero.  Certificate users SHOULD be prepared to
>    handle such certificates.

# In section 4.1.2.4 (Issuer),
# Added recommendation that pseudonym attribute type be supported.
<       * initials, and
---
>       * initials,
>       * pseudonym, and

# In section 4.2 (Standard Certificate Extensions)
# inhibit any-policy now required instead of recommended
1527,1528c1540,1542
<    (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and
<    extended key usage (see sec. 4.2.1.13).
---
>    (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), extended
>    key usage (see sec. 4.2.1.13), and inhibit any-policy (see sec.
>    4.2.1.15).
# A bit later in the same section, more of the same change
<    and inhibit any-policy (see sec. 4.2.1.15) extensions.
---
>    and policy mapping (see sec. 4.2.1.6) extensions.

# In section 4.2.1.5 (Certificate Policies),
# Clarified handling for the CPS Pointer policy qualifier.
<    The CPS Pointer qualifier contains a pointer to a Certification Prac-
<    tice Statement (CPS) published by the CA.  The pointer is in the form
<    of a URI.
---
>    The CPS Pointer qualifier contains a pointer to a Certification
>    Practice Statement (CPS) published by the CA.  The pointer is in the
>    form of a URI.  Processing requirements for this qualifier are a
>    local matter.  No action is mandated by this specification regardless
>    of the criticality value asserted for the extension.

# In section 4.2.1.6 (Policy Mappings),
# Clarified that each policy included in the issuerDomainPolicy
# component of a policy mapping should be included in the certificate
# policies extension of the certificate that contains the policy
# mapping. Otherwise, what's the point in mapping to it?
<    Policies should not be mapped either to or from the special value
<    anyPolicy. (see 4.2.1.5 certificate policies).
---
>    Each issuerDomainPolicy named in the the policy mapping extension
>    should also be asserted in a certificate policies extension in the
>    same certificate.  Policies should not be mapped either to or from
>    the special value anyPolicy. (See 4.2.1.5 certificate policies).

# In section 4.2.1.7 (Subject Alternative Name),
# Clarified that the use of the DNS representation for Internet mail
# addresses is prohibited.
<    instead of [email-masked]) is not permitted; such identities are to
---
>    instead of [email-masked]) MUST NOT be used; such identities are to

# In section 4.2.1.9 (Subject Directory Attributes),
# Removed recommendation against the subject directory attributes
# extension.
<    The subject directory attributes extension is not recommended as an
<    essential part of this profile, but it may be used in local environ-
<    ments.  This extension MUST be non-critical.
---
>    The subject directory attributes extension is used to convey
>    identification attributes (e.g.,nationality) of the subject.  The
>    extension is defined as a sequence of one or more attributes.  This
>    extension MUST be non-critical.

# In section 4.2.1.13 (Extended key usage field),
# Clarified that a certificate user can ignore unrecognized values in
# the extended key usage field.
<    If the extension is flagged critical, then the certificate MUST be
<    used only for one of the purposes indicated.
---
>    If the extension is flagged critical, then the certificate MUST only
>    be used for one of the purposes indicated. If multiple purposes are
>    indicated the application need not recognize all purposes indicated,
>    as long as the intended purpose is present and recognized.

# In section 4.2.2.1 (Authority Information Access),
# Clarified what the OCSP access descriptor indicates.
<    Status Protocol.  Additional access descriptors may be defined in
---
>    Status Protocol.  When this access descriptor appears in the
>    authority information access extension, this indicates the issuer
>    provides revocation information for this certificate through the
>    named OCSP service.  Additional access descriptors may be defined in

# In section 4.2.2.2 (Subject Information Access),
# A new section describing the subject information access extension.
> 4.2.2.2 Subject Information Access
>
>    The subject information access extension indicates how to access
>    information and services for the subject of the certificate in which
>    the extension appears. When the subject is a CA, information and
>    services may include certificate validation services and CA policy
>    data.  When the subject is an end entity, the information describes
>    the type of services offered and how to access them.  In this case,
>    the contents of this extension are defined in the protocol
>    specifications for the suported services.  This extension may be
>    included in subject or CA certificates, and it MUST be non-critical.
> 
>    id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
> 
>    SubjectInfoAccessSyntax  ::=
>            SEQUENCE SIZE (1..MAX) OF AccessDescription
> 
>    AccessDescription  ::=  SEQUENCE {
>            accessMethod          OBJECT IDENTIFIER,
>            accessLocation        GeneralName  }
> 
>    Each entry in the sequence SubjectInfoAccessSyntax describes the
>    format and location of additional information provided by the subject
>    of the certificate in which this extension appears.  The type and
>    format of the information is specified by the accessMethod field; the
>    accessLocation field specifies the location of the information.  The
>    retrieval mechanism may be implied by the accessMethod or specified
>    by accessLocation.
> 
>    This profile defines one accessMethod to be used when the subject is
>    a CA, and one access mehod to be used when the subject is an end
>    entity.  Additional access methods may be defined in the future in
>    the protocol specifications for other services.
> 
>    The id-ad-caRepository OID is used when the subject is a CA, and
>    publishes its certificates and CRLs (if issued) in a repository.  The
>    accessLocation field is defined as a GeneralName, which can take
>    several forms.  Where the information is available via http, ftp, or
>    ldap, accessLocation MUST be a uniformResourceIdentifier.  Where the
>    information is available via the directory access protocol (dap),
>    accessLocation MUST be a directoryName. When the information is
>    available via electronic mail, accessLocation MUST be an rfc822Name.
>    The semantics of other name forms of of accessLocation (when
>    accessMethod is id-ad-caRepository) are not defined by this
>    specification.
> 
>    The id-ad-timeStamping OID is used when the subject offers
>    timestamping services using the Time STamp Protocol defined in [PKIX
>    TSA].  Where the timestamping services are available via http or ftp,
>    accessLocation MUST be a uniformResourceIdentifier.  Where the
>    timestamping services are available via electronic mail,
>    accessLocation MUST be an rfc822Name.  Where timestamping services
>    are available using TCP/IP, the dNSName and ipAddress name forms may
>    be used.  The semantics of other name forms of accessLocation (when
>    accessMethod is id-ad-timeStamping) are not defined by this
>    specification.
> 
>    Additional access descriptors may be defined in other PKIX
>    specifications.
> 
>    id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
> 
>    id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
> 
>    id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }

# In section 6 (Certification Path Validation),
# Mostly minor wording changes. Clarifies that relying party can
# supply constraints via "initial state variables".
<    Certification path validation procedures for the Internet PKI are
<    based on section 12.4.3 of [X.509].  Certification path processing
<    verifies the binding between the subject distinguished name and/or
<    subject alternative name and subject public key.  The binding is lim-
<    ited by constraints which are specified in the certificates which
<    comprise the path. The basic constraints and policy constraints
<    extensions allow the certification path processing logic to automate
<    the decision making process.
<
<    This section describes an algorithm for validating certification
<    paths.  Conforming implementations of this specification are not
<    required to implement this algorithm, but MUST be functionally
---
>    Certification path validation procedures for the Internet PKI are
>    based on the algorithm supplied in [X.509].  Certification path
>    processing verifies the binding between the subject distinguished
>    name and/or subject alternative name and subject public key.  The
>    binding is limited by constraints which are specified in the
>    certificates which comprise the path and the initial state variables
>    which are specified by the relying party. The basic constraints and
>    policy constraints extensions allow the certification path processing
>    logic to automate the decision making process.
>
>    This section describes an algorithm for validating certification
>    paths.  Conforming implementations of this specification are not
>    required to implement this algorithm, but MUST provide functionality
# Removed the validity period of the public key from the set of inputs
# required by the algorithm, since it was never used in the algorithm.
<    In section 6.1, the text describes basic path validation. This text
<    assumes that all valid paths begin with certificates issued by a sin-
<    gle "most-trusted CA". The algorithm requires the public key of the
<    CA, the CA's name, the validity period of the public key, and any
<    constraints upon the set of paths which may be validated using this
<    key.
---
>    In section 6.1, the text describes basic path validation. Valid paths
>    begin with certificates issued by a "most-trusted CA".  The algorithm
>    requires the public key of the CA, the CA's name, and any constraints
>    upon the set of paths which may be validated using this key.
# Clarified the handling of the "most-trusted CA" a bit.
<    The "most-trusted CA" is a matter of policy: it could be a root CA in
<    a hierarchical PKI; the CA that issued the verifier's own
<    certificate(s); or any other CA in a network PKI.  The path valida-
<    tion procedure is the same regardless of the choice of "most-trusted
<    CA."
---
>    The selection of a "most-trusted CA" is a matter of policy: it could
>    be the top CA in a hierarchical PKI; the CA that issued the
>    verifier's own certificate(s); or any other CA in a network PKI.  The
>    path validation procedure is the same regardless of the choice of
>    "most-trusted CA."  In addition, different applications may rely on
>    different "most-trusted CA", or may accept paths that begin with any
>    of a set of "most-trusted CAs."
# Described section 6.3 here for the sake of completeness.
>    Section 6.3 describes the steps necessary to determine if a
>    certificate is revoked or on hold status when CRLs are the revocation
>    mechanism used by the certificate issuer.
> 
# Clarified that features described as optional in earlier sections
# may be omitted from this validation algorithm. They are included
# here only for completeness and clarity.
<    This text describes an algorithm for X.509 path processing.  A con-
<    formant implementation MUST include an X.509 path processing pro-
<    cedure that is functionally equivalent to the external behavior of
<    this algorithm.
<
<    This text assumes that there is a single trust anchor for certifica-
<    tion path processing, which simplifies the description of the path
<    processing procedure. This procedure can be extended to address mul-
<    tiple trust anchors, as discussed further in Section 6.2.
---
>    This text describes an algorithm for X.509 path processing.  A
>    conformant implementation MUST include an X.509 path processing
>    procedure that is functionally equivalent to the external behavior of
>    this algorithm.  However, some of the certificate fields processed in
>    this algorithm are optional for compliant implementations. Clients
>    that do not support these fields may omit the corresponding steps in
>    the path validation algorithm.
> 
>    For example, clients are not required to support the policy mapping
>    extension.  Clients that do not support this extension may omit the
>    path validation steps where policy mappings are processed. Note that
>    clients MUST reject the certificate if it contains critical
>    extensions that are not supported.
> 
>    This text describes the trust anchor as an input to the algorithm.
>    There is no requirement that the same trust anchor be used to
>    validate all certification paths.  Different trust anchors may be
>    used to validate different paths, as discussed further in Section
>    6.2.
# Minor wording changes.
<       (c) user_initial_policy_set:  A set of certificate policy identif-
<       iers naming the policies that are acceptable to the certificate
<       user. The user_initial_policy_set has the special value "any-
<       policy" if the user is not concerned about certificate policy.
---
>       (c) user-initial-policy-set:  A set of certificate policy
>       identifiers naming the policies that are acceptable to the
>       certificate user. The user-initial-policy-set contains the special
>       value any-policy if the user is not concerned about certificate
>       policy.
# Removed the issuer unique identifier from the trust anchor
# information (presumably because its use is discouraged).
<          (2) optionally, the trusted issuer unique identifier,
<          (3) the trusted public key algorithm,
<          (4) the trusted public key, and
<          (5) optionally, the trusted public key parameters associated
---
> 
>          (2) the trusted public key algorithm,
> 
>          (3) the trusted public key, and
> 
>          (4) optionally, the trusted public key parameters associated
# working_issuer_UID has been removed (although it is still referenced
# later in the algorithm).
<    The initialization phase establishes twelve state variables based
---
>    The initialization phase establishes eleven state variables based
# working_issuer_UID has been removed
<       (k) working_issuer_UID: a distinguished name may be associated
<       with an optional unique identifier.  The working_issuer_UID is the
<       unique identifier that is expected in the next certificate, or the
<       value NULL.  The working_issuer_UID is initialized to the trusted
<       issuer's unique identifier provided in the trust anchor informa-
<       tion.
# New behavior in policy processing.
>          If no node of depth i in the valid_policy_tree has a
>          valid_policy of ID-P but there is a node of depth i with a
>          valid_policy of any-policy, then generate a child node of the
>          node of depth i-1 that has a valid_policy of any-policy as
>          follows:
> 
>             (i) set the valid_policy to ID-P;
> 
>             (ii) set the qualifier_set to the qualifier set of the
>             policy any-policy in the certificate policies extension of
>             certificate i;
> 
>             (iii) set the criticality_indicator to the criticality of
>             the certificate policies extension of certificate i;
> 
>             (iv) and set the expected_policy_set to the set of
>             subjectDomainPolicy values that are specified as equivalent
>             to ID-P by the policy mappings extension.

# In section 6.2 (Using the Path Validation Algorithm),
#
# If you want to have different parameters for different trust
# anchors, the old recommendation was to place limitations in the
# self-signed certificates used as the trust anchors. The new
# recommendation is to supply different inputs to the path validation
# procedure.
<    The path validation algorithm presented in 6.1 is based on several
<    simplifying assumptions (e.g., a single trusted CA that starts all
<    valid paths). This algorithm may be extended for cases where the
<    assumptions do not hold.
<
<    This procedure may be extended for multiple trusted CAs by providing
<    a set of self-signed certificates to the validation module.  In this
<    case, a valid path could begin with any one of the self-signed certi-
<    ficates.  Limitations in the trust paths for any particular key may
<    be incorporated into the self-signed certificate's extensions. In
<    this way, the self-signed certificates permit the path validation
<    module to automatically incorporate local security policy and
<    requirements.
---
>    The path validation algorithm describes the process of validating a
>    single certification path.  While each path begins with a specific
>    trust anchor, there is no requirement that all paths validated by a
>    particular system share a single trust anchor.
>
>    The selection of one or more trusted CAs is a local decision.  A
>    system may provide any one of its trusted CAs as the trust anchor for
>    a particular path.  The inputs to the path validation algorithm may
>    be different for each path.  The inputs used to process a path may
>    reflect application-specific requirements or limitations in the trust
>    accorded a particular trust anchor.  For example, a trusted CA may
>    only be trusted for a particular certificate policy.  This
>    restriction can be expressed through the inputs to the path
>    validation procedure.

# In section 7 (References),
# Added a new reference, referred to from the Subject Information
# Access section.
>    [PKIX TSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509
>             Public Key Infrastructure Time Stamp Protocol,"
>             draft-ietf-pkix-time-stamp-12.txt, November, 2000.

# In section A.1 (Explicitly Tagged Module, 1988 Syntax),
# Added two more OIDs for use with the subject information access extension.
> id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
> id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }

# In Appendix B (ASN.1 Notes),
# Modified text to reflect the fact that zero is a valid serialNumber.
<    CAs MUST force the serialNumber to be a positive integer, that is,
---
>    CAs MUST force the serialNumber to be a non-negative integer, that
# Modified text to explicitly require certificate users to support
# serial numbers up to 20 octets in length.
<    Given the uniqueness requirements above serial numbers can be
<    expected to contain long integers. Certificate users MUST be able to
<    handle serialNumber values longer than 32 bits. Conformant CAs MUST
---
>    As noted in section 4.1.2.2,  serial numbers can be expected to
>    contain long integers. Certificate users MUST be able to handle
>    serialNumber values up to 20 octets in length. Conformant CAs MUST

---

From: Steve Hanna <[email-masked]>
Date: Wed, 29 Nov 2000 15:19:37 -0500

As I said in my earlier note, I'm very pleased with this document and I'd like
to see it go to Working Group Last Call soon. However, I do have a few
comments:

1)  The first paragraph of section 6 (Certification Path Validation) says
    the relying party can constrain the binding by specifying "initial state
    variables". But this terminology is not consistent with section 6.1.1,
    which refers to the relying party specifying "seven inputs", which are
    used during the initialization phase to establish "eleven state
    variables".

    I expect that phrase in section 6 really means that the relying party can
    constrain the binding by specifying those seven inputs. If so, then that
    paragraph should say "inputs" instead of "initial state variables". If
    not, then I would like to know what that phrase means.

2)  In new-part1-03, the issuer unique identifier was removed from the trust
    anchor information and from most parts of the validation algorithm.
    I assume that this was done because section 4.1.2.8 says "CAs conforming
    to this profile SHOULD NOT generate certificates with unique identifiers".
    I have heard on at least one occasion that "nobody uses unique
    identifiers". Certainly, I have never seen them used.

    However, section 4.1.2.8 also says "Applications conforming to this
    profile SHOULD be capable of parsing unique identifiers and making
    comparisons." If we retain this recommendation, the validation algorithm
    should include a step where unique identifiers are compared.

    In new-part1-03, the only place where unique identifiers are mentioned in
    the validation algorithm is step (a) (5) of section 6.1.3, which says:

         (5) The certificate issuer unique identifier is the
         working_issuer_UID, meaning:

            (i) working_issuer_UID is non-null and matches the value in
            the issuerUID field, or

            (ii) working_issuer_UID is null and the issuerUID field is
            not present.

    But working_issuer_UID is no longer set anywhere.

    If we really feel that unique identifiers are not useful and not used, we
    could simplify the validation algorithm by saying that any certificate
    containing an issuer unique identifier or subject unique identifier should
    be rejected. And we should change section 4.1.2.8 to reflect this.

    If, on the other hand, we want the validation algorithm to include support
    for comparing unique identifiers, we should describe in section 6.1 how
    working_issuer_UID is initialized and updated.

    I don't have a strong opinion about whether unique identifiers are useful
    and whether they are actually used. Does anybody believe that they are?

-Steve