[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on / suggested changes for RFC3280bis

To: <ietf-pkix@xxxxxxx>, "'David A. Cooper'" <david.cooper@xxxxxxxx>
Subject: Comments on / suggested changes for RFC3280bis
From: "Peter Hesse" <pmhesse@xxxxxxxxxxxxxxxxxx>
Date: Thu, 26 May 2005 11:14:27 -0400
Cc: <RGuida@xxxxxxxxxxxxx>, <MRamos8@xxxxxxxxxxxxx>, <mcooper@xxxxxxxxxxxx>, <chokhani@xxxxxxxxxxxx>, "'Zagar, Terry (Mission Systems)'" <Terry.Zagar@xxxxxxx>, "'Guy Tallent [SIG] (E-mail)'" <guy@xxxxxxxxxxxxxxxxxxxxxxxxxx>, "'Gary Secrest [JJCUS] (E-mail)'" <GSecrest@xxxxxxxxxxxxx>
In-reply-to: <232C3D7FF15B854084DB58733FFD624101FFF1A7@xxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx
Thread-index: AcVX1K4llWiL9DePTeCFxe3k0UJfvQKIX8gwAADGGJAAAGWhkAACmAwg
PKIX list and RFC3280bis editors,
 
I apologize in advance for the length of this message.  Below are comments
on the RFC3280bis draft developed on behalf of Gemini Security and the
SAFE-Biopharma Association.  The SAFE-Biopharma Association's mission is to
deliver unique electronic identity credentials for strong authentication and
for the application of digital signatures for use in electronic systems and
transactions across the bio-pharmaceutical industry.  The SAFE-Biopharma
Association manages the SAFE digital signature standard and associated
operating policies for its Members, which include the world's leading
biopharmaceutical companies, their business partners, and regulatory
agencies.

This message contains specific comments on and suggested changes to the
RFC3280bis draft.  For the most part these changes are meant to clarify and
normalize the language used to specify required behavior of certificate
processing systems and CAs/CRL issuers.  Some additional changes are
requested and reasons for them are also given.
 
A real-world example of the unclear language related to behavior causing a
problem: RFC3280 specified that the inhibitAnyPolicy extension be marked
critical.  At least one version of the Sun Java CertPath implementation
rejects any certification paths containing inhibitAnyPolicy extensions which
are not marked critical.  The wording in RFC3280 was not clear that this was
a requirement for issuers and not for implementations.  (This issue has been
fixed the current RFC3280bis draft, but remains in other places for other
extensions.)
 
I will also be providing these changes in a Word document with tracked
changes to David Cooper for his use in developing the next draft.  See below
for the actual comments.  I appreciate your willingness to consider these
changes for the next draft. 
 
Sincerely,
 
Peter Hesse
 
------------------------------------------------
 
Location: 3.3, 4th para, 6th line
Original Text: "all currently issued CRLs are updated"
Recommendation: "all currently issued CRLs are scheduled to be updated".
Reason: Whether or not the CRL is updated doesn't affect notification, it is
whether a scheduled update (specified in nextUpdate) was due to occur.
 
Location: 4.2, 2nd para, last sentence
Original Text: "The text for each extension specifies the acceptable values
for the critical field."
Recommendation: "The text for each extension specifies the acceptable values
for conforming CAs and CRL Issuers to place in the critical field.
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.1, 5th para 
Original Text: "This extension MUST NOT be marked critical."
Recommendation: "Conforming CAs MUST mark this extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.2, 2nd para, last sentence
Original Text: "Applications are not required to verify that key identifiers
match when performing certification path validation."
Recommendation: "Applications SHOULD NOT verify that key identifiers match
when performing certification path validation."
Reason: Key identifier matching is not part of determining whether or not a
certification path is valid.
 
Location: 4.2.1.2, next-to-last para
Original Text: "This extension MUST NOT be marked critical."
Recommendation:" Conforming CAs MUST mark this extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.3, 2nd para, last sentence
Original Text: "When this extension appears, it SHOULD be marked critical."
Recommendation: "When this extension appears, conforming CAs SHOULD mark it
critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.4, 3rd para, last sentence
Original Text: "If this extension is critical, the path validation software
MUST be able to interpret this extension (including the optional qualifier),
or MUST reject the certificate."
Comment: This sentence seems like an unnecessary repetition of the behavior
required on all extensions, specified in the first para of 4.2.  I recommend
this sentence be removed.
 
Location: 4.2.1.5, 5th para
Original Text: "This extension MAY be supported by CAs and/or applications,
and it SHOULD be critical."
Recommendation: "This extension MAY be supported by CAs and/or applications,
and conforming CAs SHOULD mark this extension critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.6, 3rd para, last sentence
Original Text: "If the subject field contains an empty sequence, the
subjectAltName extension MUST be marked critical."
Recommendation: Add the following sentence.  "Otherwise, conforming CAs
SHOULD mark this extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.7, 2nd para
Original Text: "Where present, this extension SHOULD NOT be marked
critical."
Recommendation: "Where present, conforming CAs SHOULD mark this extension
non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.9, 4th para, 1st sentence
Original Text: "This extension MUST appear in all CA certificates that
contain public keys used to validate digital signatures on certificates."
Recommendation: "Conforming CAs must place this extension in all CA
certificates that contain public keys used to validate digital signatures on
certificates."
Reason: This statement is in conflict with the statement "verify that
certificate i is a CA certificate through out-of-band means" in section
6.1.4.
 
Location: 4.2.1.9, 4th para, 3rd sentence
Original Text: "This extension MAY appear as a critical or non-critical
extension in CA certificates that contain public keys..."
Recommendation: "Conforming CAs MAY mark this extension as critical or
non-critical in CA certificates that contain public keys..."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.9, 4th para, last sentence
Original Text: "This extension MAY appear as a critical or non-critical
extension in end entity certificates."
Recommendation: "Conforming CAs MAY mark this extension as critical or
non-critical in end entity certificates."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.11, 4th para, last sentence
Original Text: "If the policyConstraints extension is marked critical and
the inhibitPolicyMapping field is present, applications that do not
implement support for the inhibitPolicyMapping field MUST reject the
certificate."
Comment: This seems to be encouraging different behavior depending on the
criticality of the field, which goes against the spirit of extension
processing.
 
Location: 4.2.1.12, 6th para
Original Text: "This extension MAY, at the option of the certificate issuer,
be either critical or non-critical."
Recommendation: "Conforming CAs MAY mark this extension either critical or
non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) &
normalization of text
 
Location: 4.2.1.12, 8th para
Original Text: "If the anyExtendedKeyUsage keyPurposeID is present, the
extension SHOULD NOT be critical."
Recommendation: "If the anyExtendedKeyUsage keyPurposeID is present,
conforming CAs SHOULD NOT mark this extension critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 1st para, 2nd sentence
Original Text: "The extension SHOULD be non-critical,"
Recommendation: "Conforming CAs SHOULD mark this extension non-critical,"
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 2nd para, 4th sentence
Original Text: "...not the CRL issuer, then the cRLIssuer field MUST be
present and contain the Name of the CRL issuer."
Recommendation: "...not the CRL issuer, then conforming CAs MUST include the
cRLIssuer field containing the Name of the CRL issuer."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 2nd para, 5th sentence
Original Text: "...is also the CRL issuer, then the cRLIssuer field MUST be
omitted and the distributionPoint field MUST be present."
Recommendation: "...is also the CRL issuer, then conforming CAs MUST omit
the cRLIssuer field and MUST include the distributionPoint field."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 2nd para, last sentence
Original Text: "If the distributionPoint field is omitted, cRLIssuer MUST be
present and include a Name..."
Recommendation: "If the distributionPoint field is omitted, conforming CAs
MUST include the cRLIssuer field and include a Name..."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 5th para, last sentence
Original Text: "DistributionPointName SHOULD include at least one LDAP or
HTTP URI."
Recommendation: Add the following sentence. "If both HTTP and LDAP
DistributionPointName URI values are specified, the HTTP
DistributionPointName SHOULD appear first."
Reason: Firewalls are more likely to allow HTTP through, and HTTP typically
results in faster access.  Applications typically try distribution points in
the order in which they appear.
 
Location: 4.2.2.1, 13th para, 2nd sentence
Original Text: "...and MAY specify a host name (e.g.,
ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina
ry,crossCertificatePair;binary).
Recommendation: remove ",crossCertificatePair;binary" from the example
Reason: Attributes containing cross-certificate pairs should not be
recommended.  There is no way for the client to know whether or not they
will be encountering cross-certificate pairs as opposed to certificates,
without attempting to decode them and failing.  Retrieving only
cACertificate attribute should be sufficient if LDAPv3 schema is being
followed.
 
Location: 4.2.2.1, 13th para, last sentence
Original Text: "The URI MUST list appropriate attribute descriptions for one
or more attributes holding DER [X.690] encoded certificates or
cross-certificate pairs."
Recommendation: remove "or cross-certificate pairs"
Reason: Same as above (4.2.2.1, 13th para, 2nd sentence).
 
Location: 4.2.2.1, 16th para
Original Text: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797]."
Recommendation: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797] which MUST NOT contain self-signed certificates."
Reason: Self-signed certificates retrieved externally should not be included
because they cannot be trusted,
 
Location: 4.2.2.1, 18th para
Original Text: "The semantics of other id-ad-caIssuers accessLocation name
forms are not defined."
Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP
accessLocations are specified, the HTTP accessLocation SHOULD appear first."
Reason: Same as above (4.2.1.13, 5th para, last sentence).
 
Location: 4.2.2.2, 9th para, 2nd sentence
Original Text: "...and MAY specify a host name (e.g.,
ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina
ry,crossCertificatePair;binary).
Recommendation: remove ",crossCertificatePair;binary" from the example
Reason: Same as above (4.2.2.1, 13th para, 2nd sentence).
 
Location: 4.2.2.2, 9th para, last sentence
Original Text: "The URI MUST list appropriate attribute descriptions for one
or more attributes holding DER [X.690] encoded certificates or
cross-certificate pairs."
Recommendation: remove "or cross-certificate pairs"
Reason: Same as above (4.2.2.1, 13th para, 2nd sentence).
 
Location: 4.2.2.2, 12th para
Original Text: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797]."
Recommendation: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797] which MUST NOT contain self-signed certificates."
Reason: Self-signed certificates retrieved externally should not be included
because they cannot be trusted,
 
Location: 4.2.2.2, 14th para
Original Text: "The semantics of other id-ad-caRepository accessLocation
name forms are not defined."
Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP
accessLocations are specified, the HTTP accessLocation SHOULD appear first."
Reason: Same as above (4.2.1.13, 5th para, last sentence).
 
Location: 5.1.2.5, 2nd para, 1st sentence 
Original Text: "This profile requires inclusion of nextUpdate in all CRLs
issued by conforming CRL issuers." 
Recommendation: "Conforming CRL issuers MUST include the nextUpdate field in
all CRLs."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) &
normalization of text
 
Location: 5.2.2, 2nd para
Original Text: "The issuerAltName extension SHOULD NOT be marked critical."
Recommendation: "Conforming CRL issuers SHOULD NOT mark the issuerAltName
extension critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.2.3, 1st para
Original Text: "The CRL number is a non-critical CRL extension which...MUST
include this extension in all CRLs."
Recommendation: "The CRL number is a CRL extension which...MUST include this
extension in all CRLs and MUST mark this extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) &
normalization of text
 
Location: 5.2.4, 1st para
Original Text: "The delta CRL indicator is a critical CRL extension
that...the local database without reprocessing information."
Recommendation: "The delta CRL indicator is a CRL extension that...the local
database without reprocessing information.  Conforming CRL issuers MUST mark
the delta CRL indicator extension critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) &
normalization of text
 
Location: 5.2.5, 1st para, 2nd sentence
Original Text: "Although the extension is critical, conforming
implementations are not required to support this extension."
Recommendation: "Conforming CRL Issuers MUST mark this extension critical,
but conforming implementations are not required to support this extension."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.2.6, 1st para, 2nd sentence
Original Text: "The extension MUST be non-critical."
Recommendation: "Conforming CRL issuers must mark this extension
non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.3.1, 1st para, 1st sentence
Original Text: "The reasonCode is a non-critical CRL entry extension that
identifies the reason for the certificate revocation."
Recommendation: "The reasonCode is a CRL entry extension that identifies the
reason for the certificate revocation.  Conforming CRL issuers MUST mark
this entry extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.3.2, 1st para
Original Text: "The hold instruction code is a non-critical CRL entry
extension that...placed on hold."
Recommendation: "The hold instruction code is a CRL entry extension
that...placed on hold. Conforming CRL issuers MUST mark this entry extension
non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.3.3, 1st para 
Original Text: "The invalidity date is a non-critical CRL entry extension
that...to share it with CRL users."
Recommendation: "The invalidity date is a CRL entry extension that...to
share it with CRL users.  Conforming CRL issuers MUST mark this entry
extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.3.4, 5th para, 1st sentence 
Original Text: "If used by conforming CRL issuers, this extension MUST
always be critical."
Recommendation: "If used by conforming CRL issuers, this extension MUST be
marked critical."
Reason: Normalization of text
Follow-Ups:
- Re: Comments on / suggested changes for RFC3280bis
  - From: David A. Cooper
- Re: Comments on / suggested changes for RFC3280bis
  - From: Peter Gutmann
Prev by Date: Re: [draft-ietf-pkix-sim-04.txt]
Next by Date: Re: [draft-ietf-pkix-sim-04.txt]
Previous by thread: 3280bis: key usage (13)
Next by thread: Re: Comments on / suggested changes for RFC3280bis
Index(es):
- Date
- Thread