[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP Certificate transfer syntax

To: David Chadwick <d.w.chadwick@salford.ac.uk>
Subject: Re: LDAP Certificate transfer syntax
From: Phil Griffin <phil.griffin@asn-1.com>
Date: Wed, 03 Apr 2002 17:56:03 -0500
Cc: "Housley, Russ" <rhousley@rsasecurity.com>, LDAP BIS <ietf-ldapbis@OpenLDAP.org>, PKIX <ietf-pkix@imc.org>
Organization: Griffin Consulting - http://ASN-1.com
References: <5.1.0.14.2.20020401110819.032405a8@exna07.securitydynamics.com> <5.1.0.14.2.20020403102012.031ad888@exna07.securitydynamics.com> <5.1.0.14.2.20020403125913.02ccfbd8@exna07.securitydynamics.com> <3CAB56AD.6BA85700@asn-1.com> <3CAB7B46.8A20A5AB@salford.ac.uk>

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



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

Follow-Ups:
- RE: LDAP Certificate transfer syntax
  - From: "Steven Legg" <steven.legg@adacel.com.au>

References:
- Re: LDAP Certificate transfer syntax
  - From: "Housley, Russ" <rhousley@rsasecurity.com>
- Re: LDAP Certificate transfer syntax
  - From: "Housley, Russ" <rhousley@rsasecurity.com>
- Re: LDAP Certificate transfer syntax
  - From: "Housley, Russ" <rhousley@rsasecurity.com>
- Re: LDAP Certificate transfer syntax
  - From: Phil Griffin <phil.griffin@asn-1.com>
- Re: LDAP Certificate transfer syntax
  - From: David Chadwick <d.w.chadwick@salford.ac.uk>

Prev by Date: Re: LDAP Certificate transfer syntax
Next by Date: RE: LDAP Certificate transfer syntax
Index(es):
- Chronological
- Thread