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

From: Peter Gietz <[email-masked]>
Date: Tue, 05 Nov 2002 14:11:52 +0100

Hello all,

There is a new version of  "An LDAPv3 Schema for X.509 certificates", 
which I sent to the Internet Drafts Editor.

You can find the document at 
http://www.directory.dfn.de/docs/draft-klasen-ldap-x509certificate-schema-01.txt

The changes to version 00 are noted in Apendix C.
You might remember my short presentation of the initial version at the 
pkix meeting at IETF 53.

There are still some questions to handel:

- Is it possible to get a short time-slot at thje Atlanta meeting for 
presenting the changes of this new version?

- 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?
- The draft introduces new naming attributes that should be included 
into David's Draft "LDAPv3 DN strings for use with PKIs"
  <draft-ietf-pkix-dnstrings-00.txt>. Besides x509issuer and 
x509serialNumber the allready widely used attribute emailaddress (email)
  should be taken into account.
- The draft does not yet address the problem that there are "LDAPish" 
implementations that are not able to support multi-valueelds RDNs
 (e.g.  x509serialNumber=1234+x509issuer=<dn of a CA>).
  Shall this be addressed by including a third name form with yet 
another naming attribute x509issuerSerial?
- The draft does only describe fields described in RFC 3280. Should it 
also deal with Qualified certificates (RFC 3039)?
- Should it also take into account things like userGroupName 
(draft-ietf-pkix-usergroup-01)
- Should it also take into account things like Permanent Identifier 
(draft-ietf-pkix-pi-05.txt and draft-chadwick-pkix-pidn-00.txt)?

I wanted to get some feedback on these questions before including 
respective language into the draft.

Two more questions:

- 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.
- should attribute certificates be stored in a similiar fashion?

I would love to receive comments on all this from this group.

Cheers,

Peter

-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114  
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 05 Nov 2002 11:43:02 -0500

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.

>discussion about it be held on this list instead of in private email 

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

>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 

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

---

From: Peter Gietz <[email-masked]>
Date: Wed, 06 Nov 2002 16:37:44 +0100

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

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

>    OID identifying the algorithm associated with the certified public 

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.

> 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):
>

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 

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

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

 
Peter Gietz (CEO)

---

From: Julio Sanchez <[email-masked]>
Date: Wed, 06 Nov 2002 20:38:37 +0100

Peter Gietz escribió:

> 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 
> 2.) or should I rather exchange x509SerialNumber with the RFC 2256 
> attribute serialNumber    (in analogy of the attribute mail taken from 
> RFC 2798.

The syntax for serialNumber is 1.3.6.1.4.1.1466.115.121.1.44 (Printable 
String) and does not have an ordering matching rule.

Since it is a string, all kind of things appear there, it is not 
uncommon to see different hex encodings used and you have to get it 
right everytime: left zero filling or not, separating colons or not, 
etc. If serialNumber is used, it should be very well defined how is the 
integer encoded.

I think that further use of serialNumber to hold certificate serial 
numbers should be discouraged.

Julio

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 06 Nov 2002 16:48:20 -0500

Peter:

Several of these issues are interrelated.  In particular, the points about 
referrals and DIT structure overlap.  If a client is referred to another 
LDAP server, the client cannot assume that the two servers are storing 
certificates in the same manner.  In this regard, the use of a flag in the 
rootDSE could be very helpful.

Also, something I missed in my first reading. The x509certificate is 
defined as:

    ( 1.3.6.1.4.1.10126.1.5.4.2.1
         NAME 'x509certificate'
         STRUCTURAL
         MUST ( x509serialNumber $ x509signatureAlgorithm $ x509issuer $
            x509validityNotBefore $ x509validityNotAfter $ x509subject $
            x509subjectPublicKeyInfoAlgorithm )
         MAY  ( mail $ x509authorityKeyIdentifier $
            x509authorityCertIssuer $ x509authorityCertSerialNumber $
            x509subjectKeyIdentifier $ x509keyUsage $
            x509policyInformationIdentifier $
            x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName $
            x509subjectAltNameDirectoryName $ x509subjectAltNameURI $
            x509subjectAltNameIpAddress $
            x509subjectAltNameRegisteredID $
            x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName $
            x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI $
            x509isssuerAltNameIpAddress $
            x509isssuerAltNameRegisteredID $
            x509extKeyUsage $
            x509cRLDistributionPoint $ x509certificateHolder) )

I think that another MUST attribute is needed.  The certificate itself MUST 
be stored as a binary blob.  We want to be able to get the certificate from 
the repository in a manner that preserves the DER encoding applied by the 
signer.

I respond to a few of your comments below.

>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:
>>
>>(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.
>
>x509certificate entries and keep this consistency. Alternatively they MUST 
>leave out any certificates in the person entry."
>
>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
>>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?
>
>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.

Please post the results of you implementation experiments.

>>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.
>
>include a value: x509subjectAltNameRfc822Name, x509subjectAltNameDnsName, 
>x509subjectAltNameDirectoryName, x509subjectAltNameURI , 
>x509subjectAltNameIpAddress, x509subjectAltNameRegisteredID."

Correct.  I do not know if you want the schema document to capture this 
difference or not, but CA certificates must have a subject distinguished 
name, while end entity certificates may have an empty subject distinguished 
name.

>>[SNIP]

>>serial number work?  For example (building on an example in the document):
>>
>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.
>
>serialnumber attribute (SN or rather x509SerialNumber ?) and the IssuerDN: 
>Thus (using a more simple example for conveniance):
>
>Since the first part is only one single attribute all ',' and '=' have to 
>be hex escaped.
>
>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,
>attribute serialNumber    (in analogy of the attribute mail taken from RFC 
>2798.

I have no problem using x509SerialNumber instead of serialNumber.  Since no 
one has deployed any of this stuff yet, it is probably best to pick a 
single way to handle it.

>>[SNIP]

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

RFC 3039 says:

    Compliant implementations SHALL be able to interpret the following
    attributes:

       title;
       dateOfBirth;
       placeOfBirth;
       gender;
       countryOfCitizenship; and
       countryOfResidence.

These all look like reasonable search criteria.

>>issues with the multi-valued CRL attribute.  Storage in a separate entry 
>>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.
>
>Peter Gietz

Russ

---

From: Norbert Klasen <[email-masked]>
Date: Thu, 07 Nov 2002 00:40:52 +0100

Hi,

--On Mittwoch, 6. November 2002 16:48 -0500 "Housley, Russ" 
<[email-masked]> wrote:

> I think that another MUST attribute is needed.  The certificate itself
> MUST be stored as a binary blob.  We want to be able to get the
> certificate from the repository in a manner that preserves the DER
> encoding applied by the signer.

Our intention was that the binary blob should be stored in a well known 
attribute ("userCertificate" or "caCertificate"). These are allowed in an 
x509certificate entry by including one of the auxiliary object classes 
"pkiUser" or "pkiCA":

   Entries of this structural object class MUST also have one of the
   following auxiliary object classes: "pkiUser" or "pkiCA".  This way,
   the entry can contain the certificate in the "userCertificate" or
   "cacertificate" attribute.

Norbert

---

From: Norbert Klasen <[email-masked]>
Date: Thu, 07 Nov 2002 00:48:09 +0100

--On Mittwoch, 6. November 2002 16:37 +0100 Peter Gietz 
<[email-masked]> wrote:

> included to the entries of a revoked certificates.

With hindsight, using a subclass of x509certificate seems not to be such a 
good idea. According to the standards, the structural object class of an 
entry must not change. So one would have delete the entry and then readd it 
with the new structural object class. I think that an auxiliary object 
class, which can be added to an existing entry, would be the better 
approach here.

Norbert

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 7 Nov 2002 16:51:31 +1100

Peter,

Peter Gietz wrote:
> Therefore I say that 

The Tagged Index Object for CIP relies on attributes. An improved
index object format that allowed attributes with optional component
references as the keys could always be defined.

> Well a soon as component matching is reality,

Adacel has a full implementation of component matching.

> the problem of multiple 
> Steven Legg can comment on this better.

Since an implementation of component matching could always use internal
data structures that mimic the metadata approach, component matching is
theoretically no worse than the metadata approach. Component matching
obviously permits greater space efficiency since it does not require the
duplication of certificates as subordinate entries, and their component
parts as additional attributes (e.g. in our server implementation the
component parts of certificates, CRLs, etc, are indexed directly).
This has a positive effect on the overall efficiency of a directory
server, but the bigger win is in the clients which are free of the burden
of managing all the explicit redundancy entailed in metadata approach.

> The two approaches are as 
> they could live side by side.

Agreed. The solutions can co-exist.

> value.

For the most part LDAP & X.500 attribute syntaxes don't allow
empty values. Some do, and in these cases the difference between
an empty value and an absent value is recognized and significant
in LDAP & X.500.

Regards,
Steven

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 07 Nov 2002 10:31:53 -0500

Steven:

> > In LDAP you don't have a difference between empty value and
> > non existant value.
>

This is the reason that x509subject should be MAY contain.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 07 Nov 2002 11:12:14 -0500

>   "cacertificate" attribute.

Okay.  I missed this MUST statement.

Russ

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 07 Nov 2002 11:39:36 -0800

>>> In LDAP you don't have a difference between empty value and

Please note, in LDAP and X.500, there is a difference between
an attribute having an "empty" value and an attribute not being
present (has no values).  It's just that certain syntaxes
(e.g., Directory String syntax) don't allow "empty" values.
Many others (e.g. Octet String) do.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 07 Nov 2002 11:55:22 -0800

At 03:40 PM 2002-11-06, Norbert Klasen wrote:
>Our intention was that the binary blob should be stored in a well known attribute ("userCertificate" or "caCertificate"). These are allowed in an x509certificate entry by including one of the auxiliary object classes "pkiUser" or "pkiCA":
>

But who is this MUST requirement placed upon?  Seems to be
more on the user than on either (or both) the client or server
implementation.

I suggest you modify the schema so it requires a certificate
attribute to allows be present in the structural object class
of certificate objects.  Since we have two certificate attributes,
one possible approach is to have two structural classes, one
for user certificates and one for CA certificates, each
inheriting from a common abstract class.  That is,

( 1.1.1 NAME 'x509certificate' ABSTRACT
  MUST ( x509serialNumber $ x509signatureAlgorithm
    $ x509issuer $ x509validityNotBefore $ x509validityNotAfter
    $ x509subject $ x509subjectPublicKeyInfoAlgorithm )
  MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer
    $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier
    $ x509keyUsage $ x509policyInformationIdentifier
    $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName
    $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI
    $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID
    $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName
    $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI
    $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID
    $ x509extKeyUsage $ x509cRLDistributionPoint
    $ x509certificateHolder) )

( 1.1.2 NAME 'x509userCertificate' SUP x509certificate
    MUST userCertificate )

( 1.1.3 NAME 'x509cACertificate' SUP x509certificate
    MUST cACertificate )

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 07 Nov 2002 16:23:52 -0500

Kurt:

If we take your approach, with two different classes, we can impose the 
requirement that CAs have x509subject.

     $ PublicKeyInfoAlgorithm )

     MUST userCertificate
     MAY x509subject )

( 1.1.3 NAME 'x509cACertificate' SUP x509certificate
     MUST cACertificate $ x509subject )

-- Russ

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 07 Nov 2002 13:38:03 -0800

At 01:23 PM 2002-11-07, Housley, Russ wrote:
>If we take your approach, with two different classes, we can impose the requirement that CAs have x509subject.

Yes, we could.

Another section 4.4 requirement which concerns me is:
  For the purpose of this specification, each entry with a 
  structural objectclass of x509certificate MUST have one
  and only one value of the userCertificate attribute or
  caCertificate attribute, respectively. 

This single-valued requirement should be enforced by schema
by defining one or two (depending on whether a user/ca
distinction is desired) new singled-valued x509 attribute
types of certificate syntax and having the objectclass(es)
require their presence.

That is, use schema rules to express requirements upon the
representation of the information.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Thu, 14 Nov 2002 22:04:28 +0000

Peter

We need two serial number attributes and both should exist in parallel.

The X.520 serialNumber attribute is used to form a multi-valued RDN, in
case you have more than one person with the same CN ie, to ensure
uniqueness of DNs. This has a printable string format.

The certificate serial number issued by the CA and placed in the
certificate, needs to have a new attribute, and you have defined this as
x509SerialNumber. It is an integer.

To answer some of your other questions

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

Yes

- the draft introduces new naming attributes that should be included

All 3 have been added to the revised ID, which I will issue in time for
the next IETF meeting (sorry I cant make Atlanta)

- the draft does not yet address the problem that there are "LDAPish"
implementations that are not able to support multi-valueelds RDNs (e.g. 
x509serialNumber=1234+x509issuer=<dn of a CA>). Shall this be addressed
by including a third name form with yet another naming attribute
x509issuerSerial?

This is my preferred solution, since serial number on its own is not
unique. I have added x509issuerSerial to the dnstrings ID in
anticipation.

Yes please

Yes please

- should revocation information be stored in a similiar fashion. 

Yes, we are already implementing this and writing a schema for it.

And if so how: 1.) Metadata attributes for CRLs or 2.) revocation
relevant attributes attached to the certificate entries.

We are implementing 1.)

- should attribute certificates be stored in a similiar fashion

Yes, and we are writing schema for this as well.

regards

David

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************