Subject: RE: A plan for PKIX, LDAPv3, and ;binary

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Nov 2002 20:39:12 -0500

[repost to hit both lists]
At 06:42 PM 2002-11-21, Christopher Oliva wrote:
>I have a question about point 4. Specifically the sentence: 
>
>" Rather than be silent, we suggest that the PKIX syntax and schema document state the LDAP-specific encoding used in transfer without the ;binary option but deprecate its use. "
>
>What will be the impact of "but deprecate its use" to server implementations? 

I would hope the impact would be that ALL implementations
use "userCertficate;binary".

>I would prefer to remove the last 4 words of that sentence.
>
>I would like to see a more clear statement that servers will have to support requests for userCertificate as well as userCertificate;binary.

The current LDAPv3 technical specification [RFC 3377] does not
state what is to be returned when "userCertificate" is requested
(as this is a non-conformant request).  There are clients which
expect:
        a) return the certificate using "userCertificate;binary" or
        b) return the certificate using "userCertificate".

(as well as clients which accept either)

As a server cannot support both at the same time, there is
clearly an interoperability divide between implementations
of these behaviors.  To preserve interoperability on either
side of that divide, no statement is made which would require
a server implementation to cross the divide.

That is, it is suggested that servers not be restricted in
how they respond to a non-conformant request so as to allow
current interoperability with ill-behaving clients.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Mon, 25 Nov 2002 00:38:31 +0000

"Kurt D. Zeilenga" wrote:

> of these behaviors. 

Kurt

since servers typically must support LDAPv2 and LDAPv3 at the same time,
and LDAPv2 asks for userCertificate whilst LDAPv3 should ask for
userCertificate;binary, then clearly servers today SHOULD be able to
support both types of attribute request

David

> To preserve interoperability on either

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

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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 24 Nov 2002 20:48:51 -0800

I guess I wasn't clear enough in what I said.  I meant:

  a) Some clients which request (using LDAPv3) "userCertificate"
     expect "userCertificate" to be returned.
  b) Some clients which request (using LDAPv3) "userCertificate"
     expect "userCertificate;binary" to be returned.

But I'll revise my conclusion a bit...

This makes it hard for a server to support both.  The
plan gives the choice of whether to support neither,
one or the other, or both to the implementor.  I list
both here because the implementor could return the
attribute twice (once as "userCertificate", once as
"userCertificate;binary").

Basically, the specification needs to detail the definitive
mechanism for requesting and transferring certificates in
LDAP.  Beyond that, we need to very careful not to disallow
implementations from being "liberal" with "non-strict" peers.

Kurt