RE: ;binary and userCertificate (Was: Private email ...)

["Steven Legg" <steven.legg@adacel.com.au>]

Ron,

Comments in-line.

Ramsay, Ron wrote:
> Sent: Friday, 22 February 2002 10:54
> To: Kurt D. Zeilenga
> Cc: LDAP BIS
> Subject: RE: ;binary and userCertificate (Was: Private email ...)
>
>
> Kurt,
>
> Comments inline - see [RR].
>
> Ron.
>
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Thursday, 21 February 2002 19:34
> To: Ramsay, Ron
> Cc: LDAP BIS
> Subject: RE: ;binary and userCertificate (Was: Private email ...)
>
>
> At 10:59 PM 2002-02-20, Ramsay, Ron wrote:
> >Kurt,
> >
> >It seems that much of your argument hinges on ASN.1
> definitions of LDAP
> >syntaxes. You referred me to RFC 2252 Section 4.3.2 for
> this. I read that
> >section but could find no ASN.1 definitions.

RFC 2252 is deficient in that it doesn't formally state the
corresponding ASN.1 type for each LDAP syntax. That's something
we should fix in LDAPbis. However, the correlation between
LDAP syntaxes and the ASN.1 types of X.500 attributes is pretty
obvious to anyone who supports both LDAP and X.500 (and these
are the people who are supporting ;binary for all LDAP syntaxes).

For example, given these LDAP definitions:

  ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )

  ( 2.5.21.6 NAME 'objectClasses'
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )

and this X.500 definition:

  objectClasses ATTRIBUTE ::= {
    WITH SYNTAX ObjectClassDescription
    EQUALITY MATCHING RULE objectIdentifierFirstComponentMatch
    USAGE directoryOperation
    ID { 2 5 21 6 } }

it is not hard to reach the conclusion that ObjectClassDescription is
the "ASN.1 data type definition which is referenced by the SYNTAX part
of the attribute type definition" for the objectClasses attribute.


>
> RFC 2251 says:
>    The syntax of the binary value is an ASN.1 data type definition
>    which is referenced by the "SYNTAX" part of the attribute type
>    definition.
>
> That reference is provided, for most every syntax (including
> certificate) by the table in RFC 2252, 4.3.2.
>
> [RR] If you search RFC 2252 for "SYNTAX" you will see there
> is no ASN.1 data
> type definition. There is an object identifier. We could go
> to the table,
> which you seem to regard as a reference to X.520, but look at
> a complex
> type, PresentationAddress, for example.
>
>    Values in this syntax are encoded with the representation described
>    in RFC 1278 [6].
>
> This is not ASN.1!

I observe that the description of the Certificate syntax (RFC 2252, 6.5)
has no ASN.1 and makes no specific mention of the Certificate ASN.1 type
from
X.509, yet I am 99.99% certain that when you ask for userCertificate;binary
it is the BER encoding of a value of the Certificate ASN.1 type that
you are expecting to see. You seem to be quite happy to make the leap of
faith for the Certificate syntax. Why not for the other syntaxes ?

>
> >You also seem to think there are two ways to use DNs,
>
> In LDAPv3, you can transfer each and every value syntax in
> two ways. You can transfer the string representation or
> you can transfer a BER representation.
>
> [RR] That's what you say!

That's what LDAP/X.500 implementations do!

[snip]

> >Regarding the ;binary encoding of attributes on the mailing
> list, I just
> >read, memorise and delete. I think Tim Howes was advising
> someone about
> >wrapping strings, particularly that there would be two octet
> string tags
> >around the string.
>
> If, you transfer without ;binary, the AttributeValue, an OCTET STRING,
> contains just the octets of the value.  E.g. an AttributeValue
> transferring userPassword:foo is encoded as the octets 04 03 66 6F 6F,
> not 04 05 04 03 66 6F 6F.
>
> However, If you use ;binary to transfer a value of OCTET STRING
> syntax, then the AttributeValue, itself an OCTET STRING, contains
> the BER encoding of the value.  For example, the AttributeValue
> transferring userPassword;binary:foo is encoded as the octets
> 04 05 04 03 66 6F 6F not 04 03 66 6F 6F.
>
> [RR] Didn't I say precisely this?

I believe you said "For most attributes this BER is simply an octet
string wrapping.". Kurt had the misfortune to pick a syntax from
RFC 2252 where this is actually the case. For the vast majority of the
RFC 2252 syntaxes the third octet will be something other than the
tag for OCTET STRING. For example, for a value of objectClasses;binary
the third octet will be the tag for a SEQUENCE type.

Regards,
Steven