[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP Certificate transfer syntax
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
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard