Disposition of Comments for 3280bis
David A. Cooper <david.cooper <at> nist.gov>
2005-05-04 14:48:26 GMT
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.
RSS Feed