[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Assertion values and ;binary
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
>
> *****************************************************************
>