Subject: Re: LDAP Certificate transfer syntax

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 03 Apr 2002 18:02:25 -0700

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.

---

From: David Chadwick <[email-masked]>
Date: Thu, 04 Apr 2002 13:52:03 +0100

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

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

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

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