Re: new version of draft on additional x509 certificate schema for LDAP

["Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>]

Peter:

The authors have clearly put in a lot of effort.  Thanks for your work on 
this important topic.

I have a few comments and questions.

1.  Section 2, 1st paragraph on page 5.  I am quite concerned about the 
duplication proposed.  If we take the proposed approach, there must be a 
transition period.  But the issues with duplication of the certificates 
(and CRLs) in multiple locations deserves more than a sentence.  Also, the 
discussion needs to include words like "consistency."

2.  The last paragraph of section 2 says:

   A CIP based indexing system for a wide scale distributed certificate
   repository will only be possible by using the solution proposed here.

This is a pretty strong statement.  Also, this is the first time that 
support for CIP has been raised as a requirement.  I am certainly not a CIP 
expert, and I hope that this discussion will not force me to become one, 
but I think that we need to understand why CIP is so important to LDAP 
server implementors.  Can you add a few sentences of rationale?

3.  I think that section 3 is trying to tell me that the proposed scheme is 
compatible with the long-term design, yet it is also implementable in the 
short-term.  We do not have to wait for the vision of the long term to be 
realized.  Did I get that right?

4.  Section 4.1.6 defines the attribute for subject name.  RFC 3280 allows 
the subject name in an end-entity certificate to be an empty sequence.  In 
this case, the subject alternative name must be present.  What should 
happen here?  Should the attribute be present with an empty name?  Does RFC 
2253 handle empty names?  I could not figure it out with a quick 
scan.  Also, section 4.4 indicates that x509subject must be present.

5.  Please rewrite the first sentence in section 4.1.7.  I propose:

   OID identifying the algorithm associated with the certified public key.

6.  The extended key usage extension contains a sequence of OIDs, which 
identify the key purposes.  If the sequence contains more than one OID, 
does this attribute get instantiated more than once?

7.  Given the limitations that are imposed on the CRL distribution point 
attribute in section 4.2.8, wouldn't it be better to include "FullCRL" in 
the attribute name?

8.  Please add descriptive text to section 4.3.1.  I think that this 
attribute would be placed in the directory entry associated with the 
certificate subject, not in the directory entry of the certificate.   Did I 
get that right?

9.  Section 5 requires a name form that uses a multi-valued RDN.  I believe 
that many LDAP implementations cannot handle this construct.  Perhaps there 
is an alternative.  Will the Issuer DN followed by the serial number 
work?  For example (building on an example in the document):

   SN=1234567,OU=VeriSign Trust Network,
   OU=(c) 1998 VeriSign\2c Inc. - For authorized use only,
   OU=Class 1 Public Primary Certification Authority - G2,
   O=VeriSign\2c Inc.,C=US

Next, I respond to some of the questions in your posting.

> - Can and should this draft be work of the pkix group and should the 
> discussion about it be held on this list instead of in private email 
> communications?

I think that this topic is very important to the PKIX WG.  I think it 
should be discussed on the PKIX WG list.

> - The draft does only describe fields described in RFC 3280. Should it 
> also deal with Qualified certificates (RFC 3039)?

I think it would be useful to search on some of the information that QCs 
store in subject directory attributes extension.

> - should revocation information be stored in a similiar fashion. And if so 
> how: 1.) Metadata attributes for CRLs or 2.) revocation relevant 
> attributes attached to the certificate entries.

Storage of CRLs is very important.  Presently, clients have the same issues 
with the multi-valued CRL attribute.  Storage in a separate entry 
subordinate to the CRL Issuer makes most sense to me.  One issue would be 
how long such entries need to remain on-line.  Another issue is the storage 
of delta CRLs.

> - should attribute certificates be stored in a similiar fashion?

Presently, clients have the same issues with the multi-valued attribute 
certificate attribute. If this solution is adopted for certificates, it 
should be adopted for attribute certificates and CRLs too.

Russ