Re: new version of draft on additional x509 certificate schema forLDAP

[Peter Gietz <Peter.Gietz@xxxxxxxx>]

Russ:

Thanks a lot for your valuable and detailed comments, which definitely 
will be reflected in the next version of the draft, which I intend to 
submit some time after the Atlanta meeting. BTW the next version will 
also fix some bugs that still remained in the examples, for which I 
herewith apologize..

Let me comment in line:

Housley, Russ wrote:

> 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." 

Yes you are definitely right. Current clients expect the certificate to 
be in the same directory entry than the person entry with searchable 
attributes cn, mail and serialNumber of which we untill now only 
included the mail attribute into the new object class, believing that 
that is the attribute mostly searched for. Thus for these searches, the 
redundancy proposed would not be needed. We are currently implementing 
the draft and are making experiments with clients to see what else could 
be needed. A transition period would only end, if standard clients start 
to use the new schema proposed in our draft. This is one reason for us 
to want to make this work a pkix draft to further such developments.

For now I would propose to include some more language on the issue, such as:
"Maintainers of repositories complying to this memo MUST make sure that 
the same certificates are stored in the person entry and the respective 
x509certificate entries and keep this consistency. Alternatively they 
MUST leave out any certificates in the person entry."

One could additionally define an algorithm which enables the client to 
know, whether the new schema is supported by a server. This could either 
be a bit more complicated, by searching the objectclass x509certificate 
in the Subschema entry pointed to in the rootDSE entry, or by just 
specifying a separate RootDSE attribute which specifies, if certificates 
are only stored in the x509certificate entries, of if they are
additionally stored the "traditional" way.

> 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? 

Yes I could. My point here is that a service that is not maintained on 
one single site up to now needs an indexing service to prevent a 
situation where a client has to ask the same question to a large number 
of servers. X.500 with the DISP protocoll provided a chaining mechanism 
so that a client only had to ask one server and that server would know 
which other servers to contact for the right answer via so called 
knowledge information. We don't have this mechanism in LDAP, but only 
referalls. There is a new RFC (RFC2396) specifying how referrals could 
be included into the Directory tree to provide such pointers to other 
servers. But even with this technology you would have a much bigger 
maintanence effort than with an indexing system. Therefore I say that 
for a widely distributed and scalable service a CIP based indexing 
system is a necessity. And such a system relies on attributes that can 
be stored in the index objects.

> 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? 

Well a soon as component matching is reality, the problem of multiple 
certificates can be solved with it may be even better than with our 
simple approach, allthough there might be performance issues. May be 
Steven Legg can comment on this better. The two approaches are as 
compatible as is our approach with the current "traditional" method: 
they could live side by side. As to to your second conclusion: yes, we 
believe that our approach can be used today, without big implementation 
issues. We are currently experimenting  to proove this.

> 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. 

Oops, you are right x509subject should rather be a MAY attribute.

In LDAP you don't have a difference between empty value and non existant 
value. The idea behind the draft is to have a piece of software (a 
prototype of which is allready implemented by us) that analyzes a 
certificate and creates the apropriate LDIF with the new schema. Thus a 
certificate conforming to RFC 3280 will have a conforming representation 
in LDAP.  But of course we could include additional text that duplicates 
the respective rules of RFC 3280:
"If x509subject is empty, at least one of the following attributes MUST 
include a value: x509subjectAltNameRfc822Name, 
x509subjectAltNameDnsName, x509subjectAltNameDirectoryName, 
x509subjectAltNameURI , x509subjectAltNameIpAddress, 
x509subjectAltNameRegisteredID."

> 5.  Please rewrite the first sentence in section 4.1.7.  I propose:
>
>    OID identifying the algorithm associated with the certified public 
> key. 

ACK. I was thinking of rephrasing the sentence while working on the new 
version, but then this idea somehow got lost.

> 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? 

Yes, all attributes not marked with the keyword SINGLE-VALUE can have 
multiple values.

> 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? 

Ok, good idea.

> 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? 

Another Oops, somehow the commetary on this attribute got lost :-(

Yes you got it right. There is some language about this under 4.5 but of 
course there has to be a similiar statement here with a reference to 
4.5. That is what I will do in the next version.

> 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 

Yes, I had some discussions about this with David Chadwick, and I 
allready agreed to include another alternate name form for 
implementations that are not fully LDAPv3 compliant. I just didn't have 
enough time before the cut-off date for submission.

The nameform should have DN syntax and should be constructed by an 
serialnumber attribute (SN or rather x509SerialNumber ?) and the 
IssuerDN: Thus (using a more simple example for conveniance):

x509SerialIssuer=x509SerialNumber\3D12345\2Co\3DsomeCA\2Cc\3Dsomecountry,ou=somedepartment,o=someorg,c=somecountry

Since the first part is only one single attribute all ',' and '=' have 
to be hex escaped.

This is something, David and I sort of agreed upon, but as I put this as 
one of my questions to the list, this is open for discussion.

As to sn vs x509SerialNumber:  

serialNumber was defined in X.520 and RFC 2256 as:

"This attribute contains the serial number of a device."

It thus was rather meant for hardware than for software. But it seems that it is now quite regulary 
used in the pkix context. My question is 
1.) should both attributes exist in parallel,
2.) or should I rather exchange x509SerialNumber with the RFC 2256 attribute serialNumber 
   (in analogy of the attribute mail taken from RFC 2798.
3.) or should we try to standardize the sole use of x509serialNumber 

> 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. 

Thank you.

> > - 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.

OK I will work on that in the next version. Input as to which 
information might be interesting to search for is most welcome.

> > - 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. 

This is the approach David is thinking about. We already did some work 
on defining an objectclass as subclass of x509certificate that could be 
included to the entries of a revoked certificates. This would make 
dynamic creation of CRLs possible, make delta CRLs unneccessary and 
would also ease the use of directory information for an OCSP service. 
But I see advantages of CRL entries as well, since that is the 
authoritative and signed information on revocation. But a CA could also 
sign every certificate entry by means of  RFC 2645. I don't really know 
how accepted that mechanism is though. I am looking forward to 
discussions about this.

> > - 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. 

Agreed. Again it seems that people begin thinking about this allready.

> Russ



--
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114  
D-72074 Tübingen                        email: peter.gietz@xxxxxxxx
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________