[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP Certificate transfer syntax [Virus checked]
Olaf.Schlueter@secartis.com wrote:
>
> 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.
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
> 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,
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.
> 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.
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
> (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.
>
Yes, its a short term quick fix that works. Lets hope you wont have to
use it for too long.
> Whatever you do with LDAP specs, do not break existing systems, especially
> 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
> _____________________________________________________
>
> 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: olaf.schlueter@secartis.com, Home: www.secartis.com
> _____________________________________________________
>
>
> David Chadwick
> <d.w.chadwick@salf To: Jim Sermersheim <JIMSE@novell.com>
> ord.ac.uk> cc: Kurt@OpenLDAP.org, ietf-pkix@imc.org, ietf-ldapbis@OpenLDAP.org
> 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" <Kurt@OpenLDAP.org> 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: D.W.Chadwick@salford.ac.uk
> 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)
--
*****************************************************************
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: D.W.Chadwick@salford.ac.uk
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
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard