[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP Certificate transfer syntax
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
"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
> >
> >*****************************************************************
> >