Subject: RE: Assertion values and ;binary

From: "Volpers, Helmut" <[email-masked]>
Date: Fri, 15 Mar 2002 11:23:39 +0100

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:[email-masked]]
> Sent: Donnerstag, 7. März 2002 03:17
> To: [email-masked]; [email-masked]
> 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 <[email-masked]> 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: [email-masked] 
> 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
> 
> *****************************************************************
>

---

From: David Chadwick <[email-masked]>
Date: Fri, 15 Mar 2002 21:30:29 +0000

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

---

From: [email-masked] (Mark C Smith)
Date: Fri, 15 Mar 2002 17:07:52 -0500

Volpers, Helmut wrote:

> always be the BER/DER encoding.

The recommendation in the last paragraph is not fully backwards 
compatible. Once again, section 6.5 of RFC 2252 ("Certificate") says:

    ... values in this syntax MUST only be transferred using the
    binary encoding ...

(sorry; I can't read it any other way). Because of 2252, today we have 
LDAP clients that always include ;binary (and they will continue to work 
if we adopt your recommendation). But we also have compliant LDAPv3 
servers that will not accept or recognize attribute descriptions such as 
"userCertificate" (because the ;binary, which is mandated by 2252, is 
missing). I believe that by adopting your proposal we will create a 
situation where clients that comply with this new proposal fail to 
interoperate with a server that complies with RFC 2252. Of course the 
servers will be updated in due time, but there will be some confusion in 
the meantime.

-Mark Smith
  Netscape

---

From: David Chadwick <[email-masked]>
Date: Sat, 16 Mar 2002 20:16:52 +0000

>     ... values in this syntax MUST only be transferred using the

Mark,

remember that certificates are to be removed from RFC 2252 Bis, so that
this proposed standard will no longer be the definitive voice for
certificates.

> missing).

This is probably less of a problem if these servers refuse to accept
such an attribute in a Modify operation, but would be a problem if they
accepted it and then refused to return it on a Search!

> I believe that by adopting your proposal we will create a

Yes, I did an analysis of this in a previous message of 19 Feb (I did a
2 x 2 matrix) and there would indeed be a problem with new clients not
using ;binary working with old servers that expected it.

David