All,
I agree with everything that Jim wrote in his message except that I have the
following questions/comments:
Jim wrote:
4. Section 2.3, paragraph 5. This paragraph deals with chaining of
certificates and states that DN parsing is a MUST and nothing else is
recommended. We put this in at the very end of the V2 draft with the
intention of changing it later. I know that at Microsoft we are looking at
alternate methods of building chains. I think that we want to expand this
paragraph, but I don't know what the current PKIX proposals are and I would
not wish to go beyond that point. Is there anyone out there who can tell me
what the PKIX working group is thinking on:
A. DN chaining.
B. AltIssuer/AltSubjectName chaining.
C. AltKeyId chaining in each of its three variations. keyIdentifier,
authorityCertIssuer and authorityCertSerialNumber.
[JSP: The only text in PKIX I that I can find is in section 6 as follows:
(4) the subject and issuer names chain correctly. (If the
certificate has an empty sequence in the name field, name
chaining will use the critical subjectAltNames and
issuerAltNames fields.)
However, at the 14 Jan 98 informal meeting in San Francisco we agreed that
the Cert Handling I-D will be enhanced to include the following statement:
"All subject and issuer names must be non-NULL in S/MIME-compliant v3 X.509
Certificates, except that the subject DN in a user's (i.e. end-entity)
certificate may be NULL in which case the subjectAltName extension will
include the subject's identifier and will be marked as critical." This new
rule allows the CMS IssuerAndSerialNumber syntax to be continued to be used
to identify X.509 Certificates. This also allows chaining to always occur
on the DNs. The subjectKeyIdentifier and authorityKeyIdentifier extesnions
are also required during the chaining process to distinguish between certs
issued by the same CA that have different public keys. In summary, I
believe that the current Sec 2.3, para 5 is sufficient.]
Jim wrote:
Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly. Are we going
to use these? -- I recommend that we remove the following appendixes A.5 and
A.6 as we no longer do PKI work in this document. We should "import" the
definitions of basicConstraints and keyUsage from PKIX part one and not put
them in this document.
[JSP: Recommend deleting the entire Appendix A.]
- John Pawling