[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Assertion values and ;binary
Helmut
I am happy with your recommendations. The few comments I want to add are
i) the next revision of <draft-ietf-pkix-ldap-v3-05.txt> will state that
servers must store these attributes as received and return then exactly
as received (bit perfect).
ii) I have discussed with Steven Legg whether we should also add to the
above that the native encoding for certificates is BER, so that
independent of what the LDAPBIS group decides, the presence or absence
of ;binary in LDAPv3 should not make any difference to the storage and
retrieval of certificates.
iii) X.509 does not require DER, therefore DER is not mandated in the
above. BER is sufficient for signature checking of certificates.
David
"Volpers, Helmut" wrote:
>
> Here a short history of ;binary and a proposal for the ldapbis group.
>
> History and additional Infos on handling PKI-specific attributes (;binary)
>
> 1. RFC 1777 and RFC 1778: LDAP V2
>
> RFC 1778 defines only a String representation of userCertificate ( X.509V1),
> CACertificate, authorityRevocationList, certificateRevocationList and
> crossCertificatePair.
> It introduces the notation
>
> ´{ASN}´ <hex-string>
>
> for <algorithm-parameters>
>
> But in fact some LDAP servers implementation used the notation {ASN} to
> deliver attribute values stored in ASN.1 BER .
> See the following message from year 1996:
> > Almost all attributes are readable strings, but some are ASN.1 strings,
> which
> - look like this
> > "{ASN}...Here.follows.lots.of.unreadable.text...".
> >
> > How can I decode these?
> What follows the {ASN} tag is a hex representation of the BER encoded
> value. ldapd just returns whatever quipu gives it for attributes it does
> not know about, and it's up to you to know BER to decode it. The routines
> in liblber might be useful for this, but I'm guessing not very. The short
> answer is that you need to know BER to decode it. -- Tim
>
> 2. RFC 2559 : PKIX LDAP V2 operational protocol
>
> Makes RFC1778 String representation obsolete.
> Mandates to use the syntax defined in RFC 1778 , section 2.1 for Undefined.
>
> "Values of type Undefined are encoded as if they were values of Type Octet
> String, with the string value being the BER-encoded version of the value"
>
> Mandates for PKI information that the "string value of the encoding being
> the DER-encoding of the value itself"
>
> But there is no possibility for a client to require this BER/DER encoding.
> This means that the server has to know that some attributes have to be
> handled this way.
>
> 3. LDAP V3 ;binary
>
> The LDAP V3 ; binary option allows a client
>
> - to retrieve an attribute value which will then be BER/DER encoded
> - to tell to the server to store the BER/DER value of an attribute
> without modifying it.
>
> In LDAP V3, as we saw, the use of the ;binary option has normally
> consequences on the encoding of the attribute value.
>
> 4. The PKIX LDAP V3 draft 5.1.2002-03-12
>
> <draft-ietf-pkix-ldap-v3-05.txt> says:
> "Attribute descriptions are a superset of attribute type definitions.
> They allow attribute subtyping to be specified in the LDAPv3
> protocol. The ;binary option is an exception to this. This option
> allows certificates and CRLs to be asked for and returned as binary
> values encoded using the Basic Encoding Rules [11]. The mechanism
> described in RFC2559 (PKIX LDAPv2) [1] is fully compliant with the
> ;binary option of LDAPv3. The ;binary option of attribute
> descriptions MUST be supported by all implementations."
>
> The document does not mandate DER and does not say how these attributes
> should be stored.
>
> 5. Handling the PKI attributes
>
> It seems that the way servers handle handling the ;binary option or the
> absence of the ;binary option cannot be the same for all attributes. It has
> to depend on the fact if there is an LDAP Syntax/ native Syntax defined for
> this attribute or not. For certain attributes, like the attributes used for
> PKI information, there is no possible string encoding.:
>
> For most of the attributes used for PKI information, userCertificate,
> CACertificate, authorityRevocationList, certificateRevocationList,
> crossCertificatePair, the value is always encoded using DER, and this value
> sent by the CA to be stored shall not be changed: any client shall get
> exactly the same value in a retrieval operation.
>
> There is no possible string encoding for these attributes, so the value
> should always be encoded the same way, BER-encoding, independantly on the
> presence or absence of the ;binary option.is used or not.
>
> Handling this kind of attributes does not match with the LDAP definition of
> ;binary. They have to be handled in a specific way.
>
> 6. What products do or can do:
>
> So how can products handle these facts and remain backward compatible?
>
> · with LDAP V3, for standard attributes, handle the client request the
> way RFC 2551 defines:
> - A Server getting a modify operation with ;binary has to check if the
> value is encoded in BER/DER ASN.1 and store the value unchanged.
> - A server getting a retrieval operation with ; binary shall deliver
> this stored value unchanged.
> -
> · with a number of configured attributes (basically the PKI
> information), the handling has to be independant on ;binary. The server
> shall encode them always this same way, independantly on the request
> contains ;binary or not.
> If these configured attributes are the PKI attributes userCertificate,
> CACertificate, authorityRevocationList, certificateRevocationList,
> crossCertificatePair, then
>
> - a Server will handle the modify requests
> modify replace userCertificate;binary
> and modify replace userCertificate
> the same way
>
> - a Server will handle the search requests with
> with attributes : userCertificate; binary
> or attributes : userCertificate
> also the same way
>
> 7. Recommendation
>
> We could as a recommendation say what I tried to explain in section 6.
>
> - The presence of the ;binary option always mean that the attribute
> value is BER-encoded
> - The absence of the; binary option cannot be handled the same way for
> all attributes
> · For attributes for which an LDAP Syntax /Native syntax is defined,
> the absence of ;binary has the consequence that the encoding of the value is
> the LDAP string encoding.
>
> · For attributes, which have no LDAP Syntax/Native syntax, the absence
> of the ;binary option shall be ignored. The encoding of the value shall
> always be the BER/DER encoding.
>
> Regards
>
> Patrick, Helmut
>
> > -----Original Message-----
> > From: Jim Sermersheim [mailto:JIMSE@novell.com]
> > Sent: Donnerstag, 7. März 2002 03:17
> > To: ietf-ldapbis@OpenLDAP.org; d.w.chadwick@salford.ac.uk
> > Subject: Re: Assertion values and ;binary
> >
> >
> > In 2251 4.1.7 (discussing AttributeValueAssertion), it says
> > that if the
> > binary option is is present in the attribute description, the
> > assertion
> > value is a binary encoded value. We should likely make this text
> > consistent with the similar text for attribute value (while preserving
> > the other assertion value specific text).
> >
> > This same text is missing where we talk about the assertion value in a
> > MatchingRuleAssertion (extensibleMatch). For completeness, we
> > could add
> > something there.
> >
> > Jim
> >
> > >>> David Chadwick <d.w.chadwick@salford.ac.uk> 03/06/02 11:55AM >>>
> > Dear All
> >
> > I have just been asked What if a Search request filter contains
> > attributeDescription with ;binary in it? a) is this allowed, and b)
> > does
> > it mean that the assertion syntax must be BER instead of the
> > "native"/"string" encoding. I could not find an answer in RFC 2251
> >
> > Jim, I think text will need adding to the bis-protocol document to
> > cover
> > this situation as well.
> >
> > 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