Subject: Re: LDAP Certificate transfer syntax [Virus checked]

From: [email-masked]
Date: Thu, 4 Apr 2002 22:14:35 +0200

I am puzzled. Within the PKI projects that I did participate, and those
that I am aware of, retrieving certificates from an directory, either one
dedicated to the use of PKI or an PKI-enhanced corporate directory, has
never been a problem once the correct node has been known. Neither with
special applications nor with standard ones like the popular e-mail clients
Outlook (Express) or Netscape. So Certificate transfer syntax is not a
problem, all applications that I am aware of are happily expecting a
DER-encoded X.509 certificate binary blob as the certificate, and that is a
workable solution obviously, no need for a change. The only "standard" that
we are missing is a directory profile that allows us in a standardized way
to look up user certificates by typical search items like e-mail adress or
username (a de-facto standard ldap search query is implemented in Outlook,
Netscape and Lotus Notes), and CA certificates (and CA nodes) by a given
issuer name (no de-facto standard is existing). The solution proposed in
this thread  "DIT DN match subject DN" does not resolve the "retrieve a
user certificate by search item" problem, and is for reasons already been
given by others on this list a bad solution for retrieving CA nodes by
issuer DN. What we really need is an extension of the objectClass pkiCA or
certificationAuthority by an standard attribute of type DN containing the
subject name of the CA certificate. In our projects we are currently
(mis)using the objectClass "organizationalRole" for that purpose as it
contains an attribute "RoleOccupant" with the appropriate type at least.. We
are probably missing the semantics of that class here, but it is working.

Whatever you do with LDAP specs, do not break existing systems, especially
not existing PKI-aware applications on the market.
_____________________________________________________

Olaf Schlüter
Professional Services PKI

Secartis AG -- eSolutions by Giesecke & Devrient
Bretonischer Ring 3, D-85630 Grasbrunn, Germany

Phone: +49 (0) 89 4119-7041, Fax; +49 (0) 89 4119-7402
Mobile: +49 (0) 172 8979425,
Email: [email-masked], Home: www.secartis.com
_____________________________________________________

                    David Chadwick                                                                                     
                    <d.w.chadwick@salf       To:     Jim Sermersheim <[email-masked]>                                
                    ord.ac.uk>               cc:     [email-masked], [email-masked], [email-masked]   
                    Sent by:                 Subject:     Re: LDAP Certificate transfer syntax  [Virus checked]        
                    owner-ietf-pkix@ma                                                                                 
                    il.imc.org                                                                                         

                    04.04.2002 14:52                                                                                   

Jim

these are very good points that you make. They go part way to showing
that a reason for the confused situation we have gotten into is by not
previously being precise enough about certificate syntax definitions (in
fact there was not a workable one defined). I hope the new PKIX schema
ID can be precise enough to ensure that future problems dont occur. Do
you have any suggestions to the proposed wording that I sent out

David

Jim Sermersheim wrote:
>
> I note that 2252 and 2256 both have problems with the language used to
> specify this.
>
> 2252 says that values of the Certificate syntax MUST be transferred
> using the binary encoding. It then gives two attribute descriptions
> "userCertificate;binary" and caCertificate;binary". If I create an
> attribute called printerCertificate, what am I supposed to refer to it
> as?
>
> It can be argued that the MUST here refers to the encoding, and the
> attribute descriptions are merely examples of the day.
>
> 2256 says "This attribute is to be stored and requested in the binary
> form, as 'userCertificate;binary'". Am I to believe that I must somehow
> store the ;binary option in my database? Aside from that sillines, there
> is no MUST imperative here.
>
> Jim
>
> >>> "Kurt D. Zeilenga" <[email-masked]> 04/03/02 11:36AM >>>
> This text does not clearly "MUST" the use of ;binary as
> RFC 2252 and RFC 2256 did.  As previously noted, this
> "MUST" should not be dropped as doing so will cause
> interoperability problems between implementations of
> the current technical specification and the revised
> technical specification.
>
> Kurt
>
> At 05:29 AM 2002-04-01, David Chadwick wrote:
> >Colleagues
> >
> >Here is my proposed change to the section describing the LDAP syntax
> for
> >cerificates in the PKIX id
> ><draft-pkix-ldap-schema-03.txt> which should be published before the
> end
> >of April. As this is likely to be the most contentious part of the
> new
> >ID, I thought it would be useful to distribute this text at the
> earlier
> >possible moment.
> >
> >All constructive comments welcomed
> >
> >David
> >
> >
> >3.3  Certificate Syntax
> >
> >A value in this transfer syntax is the binary octet string that
> results
> >from BER or DER-encoding of an X.509 public key certificate.  The
> >following string states the OID assigned to this syntax:
> >
> >      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
> >
> >Servers must preserve values in this syntax exactly as given when
> >storing and retrieving them.
> >
> >Note. Due to the changes from X.509(1988) to X.509(1993) and
> subsequent
> >changes to the ASN.1 definition to support certificate extensions in
> >X.509(1997), no character string transfer syntax is defined for
> >certificates. The BNF notation in RFC 1778 [12] for "User
> Certificate"
> >MUST NOT be used. Values in this syntax MUST be transferred as BER or
> >DER encoded octets. The use of the ;binary encoding option, i.e. by
> >requesting or returning the attributes with descriptions
> >"userCertificate;binary" or "caCertificate;binary" has no effect on
> the
> >transfer syntax.

--
*****************************************************************

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 161 745 8169
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

*****************************************************************
(See attached file: d.w.chadwick.vcf)

---

From: David Chadwick <[email-masked]>
Date: Fri, 05 Apr 2002 00:11:43 +0100

[email-masked] wrote:
> workable solution obviously, no need for a change. 

Unfortunately some PKIs are having problems e.g, with a mixture of
LDAPv2 and v3 clients from multiple vendors, using multiple servers from
different vendors.

>The only "standard" that

this is precisely what the PKIX LDAP schema ID is defining - matching
rules that allow you to search for certificates based on their internal
fields.

> subject name of the CA certificate. 

this is a simplistic solution that does not cater for searching for
certificates with particular expiry dates, or key usage fields, or
alternate subject names, or particular CRL distribution points etc.
Further it requires someone to pull the CA name out of the cert and to
stick it in a separate attribute. What the LDAP schema ID is defining is
a general mechanism to allow a client to store a certificate on its own
(no extra attributes are needed) and then search for it based on ANY of
its embedded fields. We have started to implement this now in OpenLDAP.

>In our projects we are currently

Yes, its a short term quick fix that works. Lets hope you wont have to
use it for too long.

> not existing PKI-aware applications on the market.

Thanks for this. We should not do this of course, but we also need to
address existing problems today as well.

David