Subject: Disposition of Comments for 3280bis

From: "David A. Cooper" <[email-masked]>
Date: Wed, 04 May 2005 10:48:26 -0400

All,

Here is the disposition of comments for 3280bis 
(http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-00.txt).  
There is a Diff file on the NIST Web site at 
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html 
that highlights the differences between RFC 3280 and draft -00 of 3280bis.

If you submitted a comment and do not believe that it was addressed in 
the disposition of comments below, please let me know and I will look 
into it.  Please note, however, that draft -00 of 3280bis was originally 
submitted on February 13 and that the disposition of comments is based 
on comments that were submitted in late 2004 (or earlier).  A few 
comments have been sent to the PKIX list about 3280bis since 
mid-February.  These comments are not addressed in 3280bis-00 or in the 
notes below, but will be considered before draft -01 of 3280bis is 
submitted.

Thanks,

Dave

-----------------------------------------------------------------------------------------------------
3280bis disposition of comments:

1) There is confusion about the use of the term "CRL issuer" in RFC 3280.

   In section 3, the explanation of the "CRL issuer" component of Figure 1
   has been modified as has the description of "CRL issuer" in section 5.
   Both note that the CRL issuer is either the CA or an entity that has
   been delegated the responsibility for issuing CRLs by the CA.

2) There is confusion about whether a CA is identified by its name alone 
or by a combination of name and key pair.  The confusion mainly focused 
on the scope of CRLs.

   Section 5 of 3280bis includes the following:

   A full and complete CRL lists all unexpired certificates issued by a CA
   that have been revoked for any reason.  (Note that since CAs and CRL
   issuers are identified by name, the scope of a CRL is not affected by
   the key used to sign the CRL or the key(s) used to sign certificates.)

3) RFC 3280 states that all certificates issued after December 31, 2003 
MUST use the UTF8String encoding of DirectoryString, with some exceptions.

   3280bis states that either the PrintableString or UTF8String encoding
   of DirectoryString MUST be used, except for previously established
   names that use a different encoding.

4) 3280bis should incorporate the rules for encoding and comparing 
internationalized name forms.

   A new section 7 has been added which covers comparing directoryNames
   using the rules from LDAP StringPrep.  Section 7 also covers the
   encoding and comparison of internationalized domain names and
   Internationalized Resource Identifiers.

5) There are problems with text in RFC 3280 regarding "name rollover" 
certificates to support an orderly migration to UTF8String

   The text about "name rollover" certificates has been deleted.

6) For validity dates, RFC 3280 imposes generation requirements for CAs 
but does not include requirements for relying parties

   3280bis says: "Conforming applications MUST be able to process validity
   dates that are encoded in either UTCTime or GeneralizedTime."  This
   applies to the thisUpdate and nextUpdate fields of CRLs as well.

7) RFC 3280 states that applications should be capable of processing 
unique identifiers, but it is not clear what, if any, processing 
requirements there are.

   3280bis explicitly states that there are no processing requirements
   associated with unique identifiers.

8) The meaning of critical vs. non-critical certificate extension should 
be clarified.

   3280 bis states:  "A certificate using system MUST reject the
   certificate if it encounters a critical extension it does not
   recognize or a critical extension that contains information that it
   can not process.  A non-critical extension MAY be ignored if it is not
   recognized, but MUST be processed if it is recognized."

9) RFC 3280 states that conforming applications must be able to process 
the name constraints extension, but does not specify which name forms 
must be supported.

   3280bis states that conforming applications MUST be able to process
   name constraints for directoryName and SHOULD be able to process name
   constraints for rfc822Name, uniformResourceIdentifier, dNSName, and
   iPAddress.  3280bis further states that conforming CAs MUST NOT impose
   name constraints on the x400Address, ediPartyName, or registeredID
   name forms.

10) RFC 3280 states that conforming applications SHOULD support the 
policyMappings extension and MUST support the policyConstraints 
extension.  It seems inappropriate to require support for the 
inhibitPolicyMapping field of policyConstraints without requiring 
support for the policyMappings extension.

   3280bis states that conforming applications MUST support the
   requireExplicitPolicy field of policyConstraints and SHOULD support
   the inhibitPolicyMapping field of policyConstraints.  3280bis further
   states that applications that support the inhibitPolicyMapping field
   of policyConstraints MUST also support the policyMappings field.
   3280bis also requires CAs to mark this policyConstraints as critical.

11) 3280bis should clearly explain that there is no requirement as part 
of path validation that authorityKeyIdentifiers and 
subjectKeyIdentifiers match.

   Section 4.2.1.2 (Subject Key Identifier) now says: "Applications are
   not required to verify that key identifiers match when performing
   certification path validation."  The requirement for issuing CAs to
   place matching key identifiers in the certificates that they issue is
   still present.

12) RFC 3280 states that one common method for generating key 
identifiers is a monotonically increasing sequence number. Shouldn't key 
identifiers be globally unique (or at least shouldn't one try to avoid 
collisions).

   The phrase "One common method for generating unique values is a
   monotonically increasing sequence of integers." has be replaced with
   "Other methods of generating unique numbers are also acceptable."

13) The descriptions of the meanings of the digitalSignature and 
nonRepudiation bits of keyUsage may need to be adjusted based on the 
work in X.509

   The new text in X.509 aligns with the text in RFC 3280.  No changes
   are required to 3280bis.  A comment has been added to the ASN.1 for
   KeyUsage stating that "recent editions of X.509 have renamed
   [the nonRepudiation] bit to contentCommitment"

14) 3280bis should note that there may be security issues associated 
with setting both the digitalSignature and nonRepudiation bits in a 
certificate.

   A sentence was added to section 4.2.1.3 (Key Usage) stating:
   "Combining the nonRepudiation bit in the keyUsage certificate
   extension with other keyUsage bits may have security implications
   depending on the context in which the certificate is to be used."

15) RFC 3280 states that the privateKeyUsagePeriod extension "SHOULD NOT 
be used within the Internet PKI."  3280bis should to changed to state 
that this may MAY be used.

   The contents of the section describing the privateKeyUsagePeriod
   extension were not changed but were moved to appendix D, a new
   appendix for listing extensions that are outside the scope of the
   profile.

16) 3280bis should state that a certificate policy OID may appear at 
most once in a certificatePolicies extension.

   A sentence was added to the first paragraph of section 4.2.1.4
   (Certificate Policies) stating this.

17) RFC 3280 states "The application software SHOULD display all user 
notices in all certificates of the certification path used, except that 
if a notice is duplicated only one copy need be displayed."  This is 
inconsistent with section 6, which specifies that only those user 
notices associated with policies that appear in every certificate in the 
path (either directly or through mapping) are returned to the 
application for display.

   Section 4.2.1.4 (Certificate Policies) states that only those user
   notices that are returned as a result of path validation are intended
   for display to the user.  It is also noted that this applies to any
   other policy qualifiers.

18) The user notice qualifier makes use of DisplayText, which is a 
CHOICE of four different string encoding options.  Unlike with 
DirectoryString in the issuer and subject fields, RFC 3280 provides no 
guidance on which encodings to use.

   3280bis states: "Conforming CAs SHOULD use the UTF8String encoding for
   explicitText, but MAY use IA5String.  Conforming CAs MUST NOT encode
   explicitText as VisibleString or BMPString."

19) For the policyMappings extension, RFC 3280 states that policies 
SHOULD NOT be mapped to or from anyPolicy, but section 6 states that 
relying parties MUST reject any certificate that includes a 
policyMappings extension that maps to or from anyPolicy.

   Section 4.2.1.5 (Policy Mappings) of 3280bis states that policies MUST
   not be mapped to or from anyPolicy.

20) RFC 3280 states that the policyMappings extension MUST be marked 
non-critical, however given the processing semantics for this extension 
it may be appropriate to mark the extension critical.  X.509 allows for 
the extension to be marked either critical or non-critical.

   3280bis states that the policyMappings extensions SHOULD be marked
   critical.

21) There is a need to be able to specify name constraints for URIs that 
limit schemes that may be specified.

   3280bis includes an extended set of rules for specifying name
   constraints on URIs.

22) The rules for specifying name constraints on DNS names are unclear. 
Does "myexample.com" satisfy a constraint of "example.com"?

   3280bis states that "DNS name restrictions are expressed as
   host.example.com.  Any DNS name that can be constructed by simply
   adding subdomains to the left hand side of the name satisfies the
   name constraint."

23) 3280bis should clearly state the rules for processing a name 
constraints extension that specifies constraints on name forms that an 
application is unable to process.

   3280bis states that if a critical name constraints extension specifies
   a constraint for a name form and a name of that name form appears in a
   subsequent certificate, then the application must either process the
   constraint or reject the certificate.

24) 3280bis needs to provide more information about the use of URIs in 
the cRLDistributionPoints extension.

   3280bis provides information about HTTP and LDAP URIs.  It indicates
   that an HTTP URI MUST point to a file containing a DER encoded CRL.
   It also provides rules for the format of an LDAP URI.

25)  RFC 3280 states that when a distribution point name in a 
cRLDistributionPoints extension is specified as a URI, the URI MUST 
include a fully qualified domain name or IP address as the host.  
3280bis should allow for the use of LDAP URIs that do not specify a host 
name.

   3280bis removes this requirement by no longer specifying that the
   encoding rules specified for URIs in the subjectAltName extension
   apply to the cRLDistributionPoints extension.  3280bis also explicitly
   states that the host name is optional in LDAP URIs in the
   cRLDistributionPoints extension.

26) RFC 3280 states that if the cRLIssuer field is present in 
cRLDistributionPoints, it MUST contain at least one X.500 DN.  3280bis 
should state that this DN must be the DN from the issuer field of the 
referenced CRL.

   3280bis states that the cRLIssuer field MUST only contain the DN from
   the issuer field of the referenced CRL and that the DN MUST be encoded
   identically in both places.

27) 3280bis should deprecate segmented CRLs by reason code.

   3280bis RECOMMENDS against segmenting CRLs by reason code and
   requires that certificates that include a cRLDistributionPoints
   extension MUST include at least one distribution point that points
   to a CRL that covers the certificate for all reasons.

28) RFC 3280 states that for the id-ad-caIssuers assess method of 
authorityInfoAccess and the id-ad-caRepository access method of 
subjectInfoAccess when the accessLocation is a directoryName the 
information is to be obtained using DAP.  This is inconsistent with the 
cRLDistributionPoints extension where the protocol used to obtain the 
information is not defined by the standard but is instead considered to 
be a local matter.

   3280bis states that for the authorityInfoAccess and subjectInfoAccess
   extensions that when accessLocation is a directoryName the protocol
   used to obtain the information from the directory is a local matter.

29) RFC 3280 states that for the id-ad-caIssuers assess method of 
authorityInfoAccess and the id-ad-caRepository access method of 
subjectInfoAccess the access location may be an http, ftp, or ldap URI 
or an rfc822Name but no information is provided on the format of the 
URIs or the format of the data that will be retrieved using these access 
methods.

   3280bis specifies the format for LDAP URIs and specifies that FTP and
   HTTP URIs must point to files that contain either certificates or
   certs-only CMS messages.  The use of rfc822Name as in accessLocation
   is not mentioned.

30) For the cRLDistributionPoints extension, RFC 3280 clearly states 
that if a single distribution point contains multiple distribution point 
names that each distribution point name describes a different mechanism 
for obtaining the same CRL, whereas distribution point names that appear 
in different distribution points may point to different CRLs.  What is 
the rule for the authorityInfoAccess and subjectInfoAccess extensions?  
If an AIA extension includes more than one instance of the 
id-ad-caIssuers access method, does each instance provide a different 
mechanism for obtaining the same information or could different 
instances of the access method point to different information.

   3280bis states that different instances of the access method may
   specify different methods for accessing the same information or may
   point to different information.

31) RFC 3280 states:  "Although the [issuingDistributionPoint] extension 
is critical, conforming implementations are not required to support this 
extension."  Some people have interpreted this to mean that 
implementations that are unable to process the extension may ignore it 
even though it is marked critical.

   The following sentence has bee added to 3280bis:  "However,
   implementations that do not support this extension MUST either treat
   the status of any certificate not listed on this CRL as unknown or
   locate another CRL that does not contain any unrecognized critical
   extensions."

32) In X.509, there is a proposal to revert to the original version of 
the issuingDistributionPoint extension, which did not include the 
onlyContainsAttributeCerts field, and a new extension has been proposed 
for attribute certificates. [Note: The design team was unable to verify 
whether this proposal has been approved in X.509]

   The design team decided to continue to use the ASN.1 from RFC 3280 for
   the issuingDistributionPoint extension.  However, the text now
   explicitly states that the onlyContainsAttributeCerts field MUST be
   set to FALSE, since 3280bis only covers public key certificates.
   When onlyContainsAttributeCerts is set to FALSE, the DER encoding
   and semantics of the issuingDistributionPoint extension are the same
   as if the onlyContainsAttributeCerts were not present.

33) The certificateIssuer CRL entry extension contains a GeneralNames.  
While RFC 3280 does not state this, there seems to be general agreement 
that the certificateIssuer extension should only contain the DN from the 
issuer field of the certificate being revoked.

   3280bis states: "Conforming CRL issuers MUST include in [the
   certificateIssuer] extension the distinguished name (DN) from the
   issuer field of the certificate that corresponds to this CRL entry.
   The encoding of the DN MUST be identical to the encoding used in the
   certificate."

34) X.509 states that a certificate may not appear in a certification 
path more than once.  3280bis should impose the same restriction.

   Section 6.1 of 3280bis states that a certificate MUST NOT appear more
   than once in a prospective certification path.

35) The path validation algorithm should indicate how to perform 
validations for times other than the current time.

   Adding information about how to perform validations for some time
   other than the current time was considered to be outside the scope
   of changes that could be made in 3280bis.

36) The criticality_indicator variable in the nodes of the 
valid_policy_tree seems to have no application in the algorithm and so 
it should be removed.

   The criticality_indicator variable has been removed from the nodes of
   the valid_policy_tree.

37) Section 6.1.2 of RFC 3280 specifies the initial values for the state 
variables.  Can these variables be set to different initial values in 
order to impose additional constraints?

   Section 6.2 of RFC 3280 already states that this is permitted.
   Section 6.2 of 3280bis includes additional text referring to the
   possibility of using certificate extensions from self-signed
   certificates to set these initial values.

38) Section 6.1.4 of RFC 3280 states that one must verify that 
intermediate certificates are CA certificates using either the contents 
of the basicConstraints extension or out-of-band means.  X.509 states 
that a version 3 certificate that does not include a basicConstraints 
extension must not be considered a CA certificate.

   3280bis states that for a version 3 intermediate certificate the
   basicConstraints extension must be present with cA set to TRUE.
   Conforming applications may either reject all version 1 and version 2
   intermediate certificates or may use out-of-band means to verify that
   they are CA certificates.

39)  In section 6.1.5, RFC 3280 states that the explicit_policy variable 
is only decremented if the final certificate in the certification path 
is not self-issued.  In X.509, the final certificate in a certification 
path is treated the same way whether it is self-issued or not.

   In order to make 3280bis consistent with X.509, 3280bis has been
   changed to state that the explicit_policy variable is always
   decremented as part of the wrap-up step, whether the final
   certificate is self-issued or not.

40) Section 6.3 of RFC 3280 states: "Conforming implementations that 
support CRLs are not required to implement this algorithm, but they MUST 
be functionally equivalent to the external behavior resulting from this 
procedure."  This should be clarified.  For example, the CRL validation 
algorithm in RFC 3280 will only validate a delta-CRL if it was signed 
using the same key as the corresponding complete CRL.  While RFC 3280 
requires CRL issuers to sign delta-CRLs using the same key as the key 
used to sign the corresponding base CRL, this is not an X.509 
requirement.  Conforming implementations should be permitted to accept 
delta-CRLs that were signed using a different key even though they are 
not required to be able to do so.

   3280bis has replaced the referenced sentence with: "Conforming
   implementations that support CRLs are not required to implement this
   algorithm, but they MUST be functionally equivalent to the external
   behavior resulting from this procedure when processing CRLs that are
   issued in conformance with this profile."

41) Section 6.3.1 of RFC 3280 states: "Note that implementations 
supporting legacy PKIs, such as RFC 1422 and X.509 version 1, will need 
an additional input indicating whether the supplied certificate is 
associated with a CA or an end entity."  What is the reason for this 
statement?  The only reason that one might need to know whether a 
certificate is a CA certificate or end entity certificate when 
validating a CRL is if the CRL includes an issuingDistributionPoint 
extension with onlyContainsUserCerts or onlyContainsCACerts set to 
TRUE.  But, when one of these is set, the algorithm in section 6.3.3 
relies on the basicConstraints extension to determine the type of 
certificate.

   The sentence quoted above has been deleted.  Section 5.2.5 (Issuing
   Distribution Point) of 3280bis now states: "If either
   onlyContainsUserCerts or onlyContainsCACerts is set to TRUE then the
   scope of the CRL MUST NOT include any version 1 or version 2
   certificates."

42) There seems to be two problems with the algorithm in section 6.3.3 
when CRLs are segmented by reason code.  The algorithm defines a value 
all-reasons that is the set of reason codes from the CRLReason type.  
The algorithm continues until CRLs are located that cover all of the 
reasons in all-reasons.  If a CRL cannot be located that covers one or 
more of the reasons in all-reasons, then the algorithm fails.  But, the 
set of reasons covered by a CRL is specified using the ReasonFlags bit 
string.  In ReasonFlags, however, "unspecified" is replaced by 
"unused".  So, the algorithm will never complete successfully when CRLs 
are segmented by reason since no CRL can specify that it covers the 
"unspecified" reason code.  It is also not clear on which CRL to include 
certificates that have been revoked with a reason code of unspecified.

   In 3280bis, "unspecified" has been removed from all-reasons.  In
   addition, section 5.2.5 (Issuing Distribution Point) of 3280bis
   states that if a CRL includes an issuingDistributionPoint extension
   with onlySomeReasons present then every certificate in the scope of
   that CRL that is revoked must be assigned a revocation reason other
   than unspecified.

43) It should be noted in 3280bis that there is a risk that two 
different CAs (or a CA and a CRL issuer) may issue certificates and CRLs 
under the same name and that if this happens there is a risk that a 
relying party will validate a certificate issued by one of these 
entities using a CRL issued by the other.

   The security considerations section of 3280bis states that CAs and CRL
   issuers should be formed in a way that reduces the likelihood of name
   collisions.  It also states that implementations validating CRLs MUST
   ensure that the certification path of the target certificate and the
   CRL issuer certification path used to validate the target certificate
   terminate at the same trust anchor.

44) The text from RFC 2510 on root key update should be included in 3280bis.

   The security considerations section of 3280bis includes a pointer to
   RFC 2510.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 04 May 2005 16:56:52 -0400

All,

The new text in section 4.2.1.10 (Name Constraints) of 3280bis for 
imposing name constraints on URIs was added based on comments from some 
of the members of the design team.  After further consideration, most of 
the members of the design team decided that the additional flexibility 
provided by the proposed new rules were not absolutely necessary and 
that adding this additional flexibility could cause problems for 
existing clients.

So, unless there are objections from the working group, the -01 draft of 
3280bis will revert to the RFC 3280 rules for name constraints on URIs.  
(The -01 draft will still require that internationalized domain names be 
compared as specified in section 7 of 3280bis).

Dave

David A. Cooper wrote:

> 21) There is a need to be able to specify name constraints for URIs 
> that limit schemes that may be specified.
>