Subject: Re: Private email re LDAP and ;binary

From: David Chadwick <[email-masked]>
Date: Tue, 19 Feb 2002 17:40:10 +0000

Hi Chris

I have copied this to the LDAPBis group for their comments

> Christopher Oliva wrote:
> 
> Hi David,
> 
> thanks very much for your response.
> 
> I have a few more questions related to this issue.
> 
> Given that the current Certificate, CertificateList (etc) definitions
> are now contained within the PKIX draft
> (http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-02.txt),
> should the discussion about this be directed to the PKIX group ? 

Well the problem is that the PKIX group dont know much about LDAP. So I
would prefer the LDAPbis folks to be involved since they do know a lot
about LDAP and about certificates in general. They dont really need to
know about PKIs to be able to comment on the schema specification and
how LDAP carries certificates.

>I
> believe the arrangement with LDAPbis was to remove the Certificate
> (etc.) definitions from their I-Ds. I suppose in this case, that it
> would be up to the PKIX working group to progress changes to the draft
> (and these syntax definitions) ?
> 

This is correct. All the X.509 attributes have been removed from core
LDAP and are now in Steven's and my ID

> The only argument for insisting on the mandatory ";binary" is the
> possibility that the old RFC 1778 string formats will be presented in
> a response. However, those old RFC 1778 syntaxes were updated by RFC
> 2559.
> 

Yes, I guess you are correct. The ;binary was really a hack job to cater
for the broken string encoding of certificates. I dont really see why we
need to use it now, if the PKIX document states specifically what the
LDAP transfer syntax is, we should just be able to just simply ask for
certificates (without ;binary) and get BER back. Since BER is the only
recognised syntax in the latest specification.

> Also, any directory server that supports PKIX (and the X.509 v2 CRL
> syntax and v3 Certificate syntax) must support the ability to encode
> X.509 extensions in their response (and clients to encode this to add
> new values). It does not appear that it is possible to encode
> extensions in the broken RFC 1778 string syntaxes.

Yes, I agree with all of the above

> Therefore the only
> option (prior to ldapv3) is the "undefined" syntax of RFC 1778 which
> is equivalent to the ";binary" encoding and RFC 2559. 

Cant comment on that without further review, which I dont have time for
at the moment.

>This would mean
> that any server supporting v2 CRL and v3 Certificates cannot possibly
> be returning/accepting the RFC 1778 string syntax therefore
> eliminating that argument.
> 

< stuff cut from earlier emails>>

> >
> > Now this has changed so that the ";binary" option is no longer a
> > subtype (see section 4.1.5 of
> >
> http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-06.txt).
> 
> > This means that current products requesting "userCertificate" in
> > requests would no longer be valid queries.
> >
> > Instead, it would be preferable to see the Certificate,
> > CertificatePair and CertificateList syntaxes in ldap have a "native
> > encoding" that is equivalent to the asn.1/binary encoding used when
> > the ";binary" option is specified. This will allow userCertificate
> to
> > be requested without ";binary".
> 
> I think the above is perfectly reasonable. I suggest you raise this
> issue on the LDAP bis email list to get their response. I am currently
> 
> not participating in the LDAP bis work. (However note that there is a
> difference between returning a binary attribute and an attribute with
> ;binary. You get an extra TLV wrapping with one - the former I think)
> 
> David
>

---

From: [email-masked] (Mark C Smith)
Date: Tue, 19 Feb 2002 13:29:40 -0500

David Chadwick wrote:

> recognised syntax in the latest specification.

Do you care about backwards compatibility? Any change to the on-the-wire 
protocol for retrieving certificates over LDAPv3 makes me nervous. The 
entire installed base of LDAPv3 servers and clients uses an 
AttributeDescription of userCertificate;binary, as mandated by RFC 2252. 
Now you are suggesting that we change all clients and servers to use 
userCertificate. What value does such a change really have? Why propose 
such a change when it will very likely break some existing implementations?

-Mark Smith
  Netscape

---

From: David Chadwick <[email-masked]>
Date: Tue, 19 Feb 2002 21:06:21 +0000

Mark C Smith wrote:

> Do you care about backwards compatibility? 

Yes. We must be backwards compatible with LDAPv3 as a minimum. But note
that up until now, LDAPv3 has not defined matching rules for any X.509
stuff, nor the syntax for many of the X.509 data structures. SO the PKIX
document is the first one in which syntaxes have been specified for
everything in X.509. Thus my point is, once syntaxes are specified and
known about, then the attributes and assertion values can be carried in
their known-about syntaxes, without any special instructions (such as
;binary) being needed. ;binary becomes an anachronism from the past and
can quietly die.
But it will be needed during a period of migration for those LDAPv3
servers that DONT know the
syntaxes of the X.509 stuff so that they will still be able to transfer
it correctly.
Therefore we should allow for both now, with the intention of phasing
out ;binary in the next version (or when it goes to full standard, say).

Thus my suggestion is that if ;binary is not used, the client and the
server must know what they are dealing with, and what its syntax is.
Values are carried in BER format. However, if ;binary is used, those
products that understand the syntax simply ignore the ;binary, those
that dont know the syntax, know they have to transfer the data as BER
encoded octets.

>Any change to the on-the-wire

I agree, they do (or should do!!)

But note that the entire installed base of LDAPv2 clients and servers
(if there are many left) dont use ;binary and can still transfer X.509
stuff successfully. So ;binary is not essential for certificates to
work.

> userCertificate.

No, not at all. Here's how it would work in practice

                  V3 Server              Older V3 Server
                  Understands            Does not understand

Client sends         OK                  Error
userCertificate                  

Client sends
userCert;binary     OK                  OK

So we have a problem with older LDAPv3 servers who dont know much about
the
syntax of the X.509 stuff they are storing, just that it should be sent
and received in BER format using ;binary. (they wont know how to match
on values either). Clearly if a client tries to add a certificate to one
of these servers without using ;binary, (this could be a v3 client
evolved from a v2 one for example) the server should reject it. Thats
OK. If another client uses ;binary the certificate can be stored, but if
the original client then tries to retrieve it, it will fail. So the rule
for clients is, to be on the safe side in the short to medium term, use
;binary.

My question to the server guys is "once you understand the syntax of
X.509 attributes and assertion values, why do you want ;binary to be
there?" You probably dont, so will be glad to see it go.

My question to v2 client migrators is "what is the big deal in adding
;binary to the X.509 attribute requests, since you will have to be
making other changes anyway when you migrate to v3"

> What value does such a change really have? Why propose

I guess in short, it tidies things up for the future, and removes an
anomaly from the standard.

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

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