Subject: LDAP Certificate transfer syntax

From: David Chadwick <[email-masked]>
Date: Mon, 01 Apr 2002 14:29:06 +0100

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: "Housley, Russ" <[email-masked]>
Date: Mon, 01 Apr 2002 11:10:05 -0500

David:

Is it possible to preserve the DER encoding.  If not, then the DER encoding 
must be restored in order to validate the signature?  This just seems like 
wasted processing to me.

Russ

---

From: David Chadwick <[email-masked]>
Date: Mon, 01 Apr 2002 22:32:59 +0100

Russ

I quite agree. The revised text is meant to ensure that the DER or BER
encoding created by the client when the certificate was first sent to
the directory for storage is preserved as is. This is the purpose of the

> >storing and retrieving them.

Perhaps I should say "as given to them by the client, when storing and
retrieving certificates"

David

---

From: Ken Stillson <[email-masked]>
Date: Tue, 2 Apr 2002 15:52:48 -0500 (EST)

> All constructive comments welcomed

  Hi David-
  A thought for the you...

  Although implied by section 3, perhaps it should be stated expectedly:

  "A PKI object should be placed into a LDAP directory such that the LDAP
   object DN matches the subject DN of the object."

  Although this seems obvious to some, I've run into a surprising number of
  clients setting up directories using some alternate structure, who are
  then surprised when validation software can't find certificates given
  subject DN's.

    - Ken Stillson

-- 
      |   Ken Stillson             |    [email-masked]    |
      |   Sr. Principal Engineer   |    voice: (703) 610-2965    |
      |   Mitretek Systems         |      fax: (703) 610-2984    |

---

From: David Chadwick <[email-masked]>
Date: Tue, 02 Apr 2002 23:39:05 +0100

>    object DN matches the subject DN of the object."

Ken

whilst I agree with you that this is an obvious thing to do, I dont
believe the ID should say how people should structure their DITs. As
this is a general standard, people are free to structure their DITs in
any way they wish to, and should still be able to use the subschema in
this ID. I think it should rather be a BCP that tells people the best
way to build their directories so that they have the minimum of hassles
operationally. (But I bet it will be difficult to get people to agree on
the contents of the BCP)

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

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

---

From: Harald Koch <[email-masked]>
Date: Wed, 03 Apr 2002 00:08:14 -0500

Of all the gin joints in all the towns in all the world, Ken Stillson
>    object DN matches the subject DN of the object."

It's supposed to be the other way around, isn't it? One should issue
certificates with a subject DN that matches the LDAP object DN.

Anyway, there are many environments where a certificate issued by one
organisation must be stored in a directory belonging to another. I don't
believe that an arbitrary restriction like this won't fly.

-- 
Harald Koch     <[email-masked]>

---

From: Michael Ströder <[email-masked]>
Date: Wed, 03 Apr 2002 09:33:30 +0200

>   then surprised when validation software can't find certificates given

Ken, for various reasons this old style 1:1 DIT mapping and obtaining the 
certificate chain from a directory never really worked in practice. Maybe in 
some small environments or very specific environments. It also assumes that 
the CA and the LDAP directory are structured and maintained by the same 
authority which is most times not true in e.g. bigger companies.
BTW: Which implementation do exist outside the X.500 world which try to 
obtain the whole certificate chain from a LDAP directory? I do not know a 
single one.

Also think of dc-style naming vs. traditional X521 naming. If you'd like to 
use dc-style naming in your LDAP directory and have that DIT 1:1 in your 
certificate's subject name you will run into many serious interoperability 
problems with PKI enabled software.

Ciao, Michael. (somewhat sick of DIT discussions)

---

From: Ken Stillson <[email-masked]>
Date: Wed, 3 Apr 2002 10:00:46 -0500 (EST)

On Wed, 3 Apr 2002, Michael Ströder wrote:
> some small environments or very specific environments.

  As I understand it, this is the approach being taken in the rather large
  effort of the Federal Bridge CA (FBCA).  Perhaps it's not an ideal
  solution, but at the moment, it appears to be the only available solution.

  The problem is that when finding the next certificate in a hierarchical or
  cross-cert chain, validation software might (when AIA and similar
  extensions are not populated) only have the issuer field of the current
  cert in order to find the next certificate.

  (David W. informs me that an outcome of the LDAP PKIX ID will be the
   ability to search for an entry based on its internal cert DN rather than
   ldap-read it from a directory location.  I hadn't caught that; perhaps
   that's the permanent solution.  I'm coming from the point of view of the
   FBCA project which is already well underway and didn't have that
   capability available to rely upon.)

> obtain the whole certificate chain from a LDAP directory? I do not know a

  FBCA is using a combination of chained X.500 directories (with LDAP
  front-ends), and LDAP "meta-directories," essentially a mesh of referral
  systems.

> problems with PKI enabled software.

  Well, I guess I would say that if one "would like" dc-style naming, then
  that directory is designed for human interaction (humans "like" things).

  A PKI repository being stood-up for automated certificate retrieval should
  be structured for the ease of retrieval; if one really needs both, and
  they conflict, it wouldn't be too surprising to need two structures;  at
  least two indexing structures (I believe most directory software would
  allow referrals or aliases to provide two DN views to the same objects).

    - Ken

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 03 Apr 2002 10:21:39 -0500

David:

I would like to encourage clients to provide certificates in DER.  We ought 
to tell them that there will be less work for everyone if they provide 
DER-encoded certificates.  Likewise for CRLs.

Russ

---

From: [email-masked] (Mark C Smith)
Date: Wed, 03 Apr 2002 11:16:49 -0500

I am still concerned about how dropping the ;binary transfer option that 
was mandated by RFC 2252 will affect the large installed base of LDAPv3 
and PKI implementations (of course some PKI clients are already trying 
to use userCertificate without ;binary with LDAPv3 implementations, and 
not surprisingly there are having a difficult time).

But if consensus is to proceed with this proposal, then I think the 
conflict with RFC 2252 should be noted in the PKIX document (there is a 
lot of history behind all of this, and implementors and users who do not 
know all of it will undoubtedly be confused).

-Mark Smith
  Netscape

---

From: David Chadwick <[email-masked]>
Date: Wed, 03 Apr 2002 18:45:10 +0100

Mark

We are not dropping the ;binary option, you can still use it, but its
functionality is redundant as the "native" LDAP encoding is BER.

To put the other view, I have heard that some other LDAPv3 directories
are unable to accept the ;binary option anyway. So what I am now arguing
for is leniency on the part of servers, that they neither demand nor
reject the use of ;binary, but just ignore it if it is there.

David

---

From: David Chadwick <[email-masked]>
Date: Wed, 03 Apr 2002 18:39:26 +0100

Russ

I dont think the issue below is one for the schema ID. The certificate
attributes in the directory should be perfectly happy to receive BER or
DER (or PER for that matter I guess). So the schema ID should allow
anything to be stored there.

Your issue is more one for the LDAP profile ID which was last updated in
January. In the profile we can suggest that clients always use DER for
encoding certificates.  But what is the common WG concensus on this? FYI
in recent work we did with attribute certificates we found we had to use
BER because the DER Java objects were too buggy.

David

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 03 Apr 2002 09:58:22 -0800

At 08:16 AM 2002-04-03, Mark C Smith wrote:
>I am still concerned about how dropping the ;binary transfer option that was mandated by RFC 2252 will affect the large installed base of LDAPv3 and PKI implementations (of course some PKI clients are already trying to use userCertificate without ;binary with LDAPv3 implementations, and not surprisingly there are having a difficult time).

I fully concur.  The PKI schema specification needs to be
revised in a manner which doesn't introduce significant
backwards compatibility problems with implementations of
the current LDAPv3 technical specification.

Kurt

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 03 Apr 2002 13:05:59 -0500

David:

When DAP is used, certificates come back in BER.  This happens because the 
DAP PDU is defined in ASN.1, and the BER encoding of the PDU encodes the 
data too.  An OCTET STRING could have been used, but this was all done 
before there were object that had signatures.  Anyway, I see this as an 
opportunity to do better.

I do not know about your AC development experience, but the specifications 
are quite clear about the need for DER.  It would be nice if the repository 
fetch did not force the client to restore the original DER encoding.

I agree that this is not a schema issue. However, a comment that the DER 
encoding applied by the signer should be preserved is all I really 
want.  You have already fixed the problem where the repository access 
protocol is changing the encoding.

Russ

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 03 Apr 2002 10:36:25 -0800

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

---

From: David Chadwick <[email-masked]>
Date: Wed, 03 Apr 2002 19:56:07 +0100

Kurt

I dont believe we are introducing significant backwards compatibility
problems (though there are some, see below) and we are removing forwards
compatibility problems which is a big plus. Given that there are many
fewer server implementations than clients, it will be easier to migrate
these to be ;binary lenient than to migrate lots of clients.

What the PKIX spec is in fact doing, which has never been done before
but should have been, is to specify a "native" encoding for certificates
that says they are BER or DER encoded byte strings. Thus the ;binary
option can be used, but it is a null function. It is also saying, which
again should have been said a long time ago but never was, is that
servers MUST NOT change the encoding of certificates when they recieve
them, but MUST leave them exactly as received and return them exactly as
received.

Now to the backwards compatibility issues. In the table below the only
problem will come with a new LDAPv3 client that does not use ;binary
with an existing v3 server that demands it. But we already have an
inconsistency in these current LDAPv3 servers in that they accept LDAPv2
queries without ;binary but not LDAPv3 queries without ;binary. But they
sometimes screw things up because a certificate stored by an LDAPv2
client cannot always be retrieved by an LDAPv3 client (which you have to
admit is pretty crazy). The new schema spec will remove all of these
problems once the servers become less religious about the presence of
;binary, and are configured to know that a certificate's native encoding
is already BER/DER.

                    Current LDAPv3 Server       NewLDAPv3Server
                    mandates ;binary            does not care

LDAPv2 client
does not use             seems to work                 OK  
;binary

Current LDAPv3 client       OK                        OK
does use ;binary

New LDAPv3 client         probably
does not use              wont work                   OK
;binary

I honestly believe that what is being proposed is the best solution to
what at present is a very messy LDAP world, as far as PKI is concerned

David

---

From: Phil Griffin <[email-masked]>
Date: Wed, 03 Apr 2002 14:23:25 -0500

Forgive me if I'm wrong here, but I had the understanding 
that the outermost sequence wrapper of a certificate was
a BER encoding, and the the inner content "ToBeSigned"
is required to be encoded using DER.

I think the point here should be, regardless of how the
certificate was initially encoded, it should be treated
as an open type, a value of type Certificate in its 
encoded form, and that the encoding received by the 
Directory should be preserved, and that preserved form
of the data should be returned to a requester.

If this is done, then the concerns Russ raises as to
requiring extra processing disappear, and the issue that
David raised as to whether the protocol can be extended 
to other encodings (BER or CER or PER or XER) is also mute.

The Directory just knows it has a blob. It stores the blob
as given and can return the blob on demand. 

Phil

---

From: Mark Wahl <[email-masked]>
Date: Wed, 03 Apr 2002 13:50:57 -0600

David Chadwick wrote:
> queries without ;binary but not LDAPv3 queries without ;binary. 

I do not think LDAPv2-LDAPv3 behavior is sufficient justification to cause 
incompatibility between two LDAPv3 implementations.

Maybe an "LDAPv4" should have a different way for clients to send  
certificate, but LDAPv2 compatibility should not be a concern that causes
this significant a change inside of the LDAPv3 specs.  That is out of scope 
for LDAPBIS.

Mark Wahl
Sun Microsystems Inc.

---

From: David Chadwick <[email-masked]>
Date: Wed, 03 Apr 2002 22:59:35 +0100

Phil

thanks for this. But there is one further point, and that concerns
certificate matching which is the other topic of the schema ID. For this
to work, the server has to parse the blob and extract the various fields
to be used in subsequent searches. Therefore the server needs to be told
what transfer syntax the blob is being sent in. The current proposed
text only allows the blob to be BER or DER and not PER or XER encoded.
To allow the latter we would need to introduce new LDAP transfer
encoding keywords such as ;PER and ;XML. The current ;binary keyword
specifically means BER encoding. (And because DER is a subset of BER
then ;binary is taken to mean DER as well, which maybe it should not if
we were to be really strict?).

David

---

From: Phil Griffin <[email-masked]>
Date: Wed, 03 Apr 2002 17:56:03 -0500

David,

Understood and agree. My point though is that if
the format of the initial encoding is preserved 
as an open type, it doesn't much matter what it 
happened to be when it was signed. 

It is only when someone tries to reconstruct the
certificate from its values using the strict DER 
subset of BER that a mismatch with the signature 
due to BER/DER differences in the encoding can 
arise.

And as you've stated, technically when you say BER 
you've included DER, as DER is a subset. But if 
you are talking about a protocol requirement you
may need to be careful with the language and try 
to be as explicit as possible.

Surely if ;binary means BER it is not illegal to 
return DER. But if ;binary means DER, then it would
seem that returning BER that is not from the DER 
subset would be illegal. 

And if a ;binary object is a BER wrapper around a
DER encoding, then that's another case. 

Phil

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 4 Apr 2002 12:59:37 +1000

Phil,

Phil Griffin wrote:
> Sent: Thursday, 4 April 2002 8:56
> To: David Chadwick
> Cc: Housley, Russ; LDAP BIS; PKIX
> Subject: Re: LDAP Certificate transfer syntax
> 
> 
> 
> David,
> 

In LDAPv3, ;binary specifies BER with no requirement to preserve
the exact octets of the encoding. A server is theoretically
allowed to return any valid BER encoding of the abstract value.

However typical client usage of userCertificate;binary depends
on the exact octets being preserved by the server. In the PKIX
LDAP schema we are making the Certificate and related syntaxes
explicit exceptions in that the exact octets of the ;binary
encoding will be preserved. If the client provides DER they will
get back DER. If they provide non-DER BER they will get back the
same non-DER octets.

I've encountered certificates where the signature was calculated
on the provided non-DER BER encoding, so specifying that the
;binary encoding of values of the Certificate syntax is a DER
encoding would break some implementations.

> DER encoding, then that's another case.

Preserving the exact BER encoding makes this subtlety unimportant.

Regards,
Steven
 
> > > > > > > > Is it possible to preserve the DER encoding.  
> If not, then the DER
> > > > > encoding
> > > > > > > > must be restored in order to validate the 
> signature?  This just
> > > > > seems like
> > > > > > > > wasted processing to me.
> > > > > > > >
> > > > > > >
> > > > > > >Russ
> > > > > > >
> > > > >X.500/LDAP Seminars: 
http://www.salford.ac.uk/its024/seminars.htm