Repost of follow-up message
At 03:54 PM 9/29/97 -0700, Anil R. Gangolli wrote:
David Solo wrote:
... I agree with just about everything Dave said. A few exceptions
below.
Certificate chains MUST be based on the Distinguished Name
of the certificates, not the subjectAltName field. [[Note: there
was some disagreement about this, and it is an open issue.]]
You can include me as one of the disagree-ers.
Dave, do you have an alternative suggestion?
e.g.
- S/MIME implementations MUST support chain formation based on
subjectAltNames and issuerAltNames fields.
People seemed opposed to this in this draft.
- S/MIME implementations SHOULD support chain formation ... as in
previous statement; and stregthen in
a future draft.
- no statement at all
Part of the question is to whom the requirement applies. A statement that
clients MUST support chaining by DN and MAY/SHOULD support chaining by
altName is OK. I'm not sure if the intent of the original language is to
also preclude a CA cert with a null DN. While doing this may be necessary,
it does require enterprise CAs to have to choose a DN. I can live with either.
Sending and receiving agents MUST correctly handle the v3 Basic
Constraints Certificate Extension, the Key Usage Certificate
Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when
they appear in end-user certificates. Some mechanism SHOULD exist to
handle the defined v3 certificate extensions when they appear in
intermediate or CA certificates.
In the S/MIME environment, CAs which issue v3 certificates SHOULD
include only the extensions listed here.
For these extensions, the criticality flag SHOULD be set to False
unless the proper handling of the corresponding extension is deemed
critical to the correct interpretation of the associated certificate.
Also, in an S/MIME environment, when additional v3 extensions are
included in a certificate, the corresponding criticality flags SHOULD
be set to False.
Replace with:
Certificates issued for the S/MIME environment SHOULD not contain any
critical extensions other than those listed here. These extensions
SHOULD
be marked as non-critical unless the proper handling of the extension
is
deemed critical to the correct interpretation of the associated
certificate.
When other extensions are included, those extensions MUST be marked as
non-critical.
I think the last two sentences needs to be clarified. The way
I'm interpreting them right now, I would disagree.
If by "these" you mean those listed above, and by "other" you mean
anything else, you're not allowing for extensions that the
issuer wishes to require that implementations consider.
I agree with you - the wording is still wrong. I think the general intent
is to encourage limiting extensions to the ones listed here and to strongly
recommend that any other extensions be non-critical. Having the extensions
listed in this section be critical is OK. Does replacing the last two
sentences with "Other extensions MAY be included by the issuer but SHOULD be
marked non-critical." work?
...
Does this mean that as part of cert path validation, if the keyUsage
field
is present for a CA, the certSign bit must be set?
Yes, but why are we getting into this here?
Actually, it doesn't belong here, but its missing from the cert path
processing description in PKIX.
--
Anil R. Gangolli
Structured Arts Consulting Group
mailto:gangolli(_at_)StructuredArts(_dot_)com
http://www.StructuredArts.com
Dave