[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: LDAP Certificate transfer syntax

To: "'Phil Griffin'" <phil.griffin@asn-1.com>
Subject: RE: LDAP Certificate transfer syntax
From: "Steven Legg" <steven.legg@adacel.com.au>
Date: Thu, 4 Apr 2002 12:59:37 +1000
Cc: "'LDAP BIS'" <ietf-ldapbis@OpenLDAP.org>, "'PKIX'" <ietf-pkix@imc.org>
Importance: Normal
In-reply-to: <3CAB8883.FD9CDC35@asn-1.com>
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,
> 
> 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.

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.

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

Preserving the exact BER encoding makes this subtlety unimportant.

Regards,
Steven
 
> 
> Phil
> 
> 
> 
> David Chadwick wrote:
> > 
> > Phil Griffin wrote:
> > 
> > > 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
> > 
> > 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
> > 
> > >
> > > Phil
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > 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
> > > >
> > > > At 06:39 PM 4/3/2002 +0100, David Chadwick wrote:
> > > > >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
> > > > >
> > > > >
> > > > >"Housley, Russ" wrote:
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > At 10:32 PM 4/1/2002 +0100, David Chadwick wrote:
> > > > > >
> > > > > > >"Housley, Russ" wrote:
> > > > > > > >
> > > > > > > > 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
> > > > > > >
> > > > > > >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
> > > > > > >sentence below in the revised text, viz:
> > > > > > >
> > > > > > > > >Servers must preserve values in this syntax 
> exactly as given when
> > > > > > > > >storing and retrieving them.
> > > > > > > > >
> > > > > > >
> > > > > > >Perhaps I should say "as given to them by the 
> client, when storing and
> > > > > > >retrieving certificates"
> > > > > > >
> > > > > > >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: 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
> > > >
> > > >*****************************************************************
> > > >
> 
> --
> *****************************************************************
> 
> 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
> 
> *****************************************************************
References:
- Re: LDAP Certificate transfer syntax
  - From: Phil Griffin <phil.griffin@asn-1.com>
Prev by Date: RE: LDAP Certificate transfer syntax
Next by Date: RE: LDAP Certificate transfer syntax
Index(es):
- Chronological
- Thread