[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Private email re LDAP and ;binary
Hi Chris
I have copied this to the LDAPBis group for their comments
> Christopher Oliva wrote:
>
> Hi David,
>
> thanks very much for your response.
>
> I have a few more questions related to this issue.
>
> Given that the current Certificate, CertificateList (etc) definitions
> are now contained within the PKIX draft
> (http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-02.txt),
> should the discussion about this be directed to the PKIX group ?
Well the problem is that the PKIX group dont know much about LDAP. So I
would prefer the LDAPbis folks to be involved since they do know a lot
about LDAP and about certificates in general. They dont really need to
know about PKIs to be able to comment on the schema specification and
how LDAP carries certificates.
>I
> believe the arrangement with LDAPbis was to remove the Certificate
> (etc.) definitions from their I-Ds. I suppose in this case, that it
> would be up to the PKIX working group to progress changes to the draft
> (and these syntax definitions) ?
>
This is correct. All the X.509 attributes have been removed from core
LDAP and are now in Steven's and my ID
> The only argument for insisting on the mandatory ";binary" is the
> possibility that the old RFC 1778 string formats will be presented in
> a response. However, those old RFC 1778 syntaxes were updated by RFC
> 2559.
>
Yes, I guess you are correct. The ;binary was really a hack job to cater
for the broken string encoding of certificates. I dont really see why we
need to use it now, if the PKIX document states specifically what the
LDAP transfer syntax is, we should just be able to just simply ask for
certificates (without ;binary) and get BER back. Since BER is the only
recognised syntax in the latest specification.
> Also, any directory server that supports PKIX (and the X.509 v2 CRL
> syntax and v3 Certificate syntax) must support the ability to encode
> X.509 extensions in their response (and clients to encode this to add
> new values). It does not appear that it is possible to encode
> extensions in the broken RFC 1778 string syntaxes.
Yes, I agree with all of the above
> Therefore the only
> option (prior to ldapv3) is the "undefined" syntax of RFC 1778 which
> is equivalent to the ";binary" encoding and RFC 2559.
Cant comment on that without further review, which I dont have time for
at the moment.
>This would mean
> that any server supporting v2 CRL and v3 Certificates cannot possibly
> be returning/accepting the RFC 1778 string syntax therefore
> eliminating that argument.
>
< stuff cut from earlier emails>>
> >
> > Now this has changed so that the ";binary" option is no longer a
> > subtype (see section 4.1.5 of
> >
> http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-06.txt).
>
> > This means that current products requesting "userCertificate" in
> > requests would no longer be valid queries.
> >
> > Instead, it would be preferable to see the Certificate,
> > CertificatePair and CertificateList syntaxes in ldap have a "native
> > encoding" that is equivalent to the asn.1/binary encoding used when
> > the ";binary" option is specified. This will allow userCertificate
> to
> > be requested without ";binary".
>
> I think the above is perfectly reasonable. I suggest you raise this
> issue on the LDAP bis email list to get their response. I am currently
>
> not participating in the LDAP bis work. (However note that there is a
> difference between returning a binary attribute and an attribute with
> ;binary. You get an extra TLV wrapping with one - the former I think)
>
> David
>
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