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

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 22 Feb 2002 10:53:56 +1100

Kurt,

Comments inline - see [RR].

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
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 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!

>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!

>in particular, the use
>of a DN as an attribute value allows the X.500 encoding. But look at
Section
>6.9 of RFC 2252 -
>
>   Values in the Distinguished Name syntax are encoded to have the
>   representation defined in [5].  Note that this representation is not
>   reversible to an ASN.1 encoding used in X.500 for Distinguished
>   Names, as the CHOICE of any DirectoryString element in an RDN is no
>   longer known.
>
>That is, ALL DNs are strings and no other definition exists for them.

That's paragraph is not precise.  Each DN has multiple string 
representations.  While some of these representations may not
be reversible, each DN does have a reversible string
representation.  That form should be used when reversibility
is desired.

[RR] Pardon! Please provide an example. A reference would also be nice. But
thanks for the information that RFC 2252 is not to be believed - I think it
cancels all of your arguments.

>You also make some statement about X.500 gateways.

I make statements about LDAP/DAP gateways.  The term "X.500
gateway" is misleading as both LDAP and DAP are access protocols
to X.500 directories.

>If gatewaying were part of the LDAP standard

I never said it was.  But LDAP is certainly designed to allow
implementation of DAP/LDAP gateways.

[RR] Desiged how? Could you give me a reference.

>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?

Kurt

---

From: Phil Griffin <[email-masked]>
Date: Thu, 21 Feb 2002 19:20:00 -0500

>    Values in this syntax are encoded with the representation described

<snip>

SYNTAX is an ASN.1 keyword but it is not a type 
name or an object or a class. It is part of the
notation provided as part of an information 
object class definition and is used to describe
objects of a given class.

For example, in X.509 the definition of the 
EXTENSION class provides a useful notation
so that users can define specific extension
objects

   EXTENSION ::= CLASS {
      &id   OBJECT IDENTIFIER UNIQUE,
      &ExtnType 
   }
   WITH SYNTAX { 
      SYNTAX        &ExtnType
      IDENTIFIED BY &id 
   }

the notation "SYNTAX &ExtnType IDENTIFIED BY &id"
indicates that the EXTENSION class field "&ExtnType"
is an open type, which can be any ASN.1 type. &id
is the value of an OID and the UNIQUE modifier 
states that each OID in an information object
set of class EXTENSION must be unique in that
context.

Generally, information objects are placed in sets
and used to bind the valid values in two or more
components of a sequence, so that (for example)
when the OID id-ce-authorityKeyIdentifier appears
in one component of a sequence, a value of type 
AuthorityKeyIdentifier is the only valid value 
allowed in an associated component.

This is really ANY DEFINED BY corrected and made
to be of actual use by ASN.1 tools in enforcing a
given schema (specification). This notation is not
defined in the superseded X.208 standard, but is a
part of the current ASN.1 standards available for 
free on the web at
http://www.itu.int/ITU-T/studygroups/com17/languages/index.html
and in the draft version of the 2002 edition at
Host: ftp://ties.itu.int login: asn1 password: notation1

So, SYNTAX is ASN.1, but it's probably correct to
say it's not treated as actual ASN.1 in the context
of LDAP.

Phil Griffin

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 22 Feb 2002 16:01:00 +1100

Ron,

Comments in-line.

Ramsay, Ron wrote:
> Sent: Friday, 22 February 2002 10:54
> To: Kurt D. Zeilenga
> Cc: LDAP BIS

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.

>    Values in this syntax are encoded with the representation described

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 ?

> [RR] That's what you say!

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

[snip]

> [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