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

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 22 Feb 2002 11:57:34 +1100

Thanks, Phil, but I thought Kurt was referring to LDAP. He has been arguing
that LDAP defines an ASN.1 type for its syntaxes, because he wants ;binary
to transfer this type, but I have failed to find specific references in the
LDAP specs.

For x.500, I'm with you 100% - we use X.500 ourselves!

Ron.

-----Original Message-----
From: Phil Griffin [mailto:[email-masked]]
Sent: Friday, 22 February 2002 11:20
To: LDAP BIS
Subject: Re: ;binary and userCertificate (Was: Private email ...)

"Ramsay, Ron" wrote (in part):
> 
> 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!

<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: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Feb 2002 20:23:00 -0800

>to transfer this type, but I have failed to find specific references in the

Even if ;binary was stricken from RFC 2251, I would argue
that there is the LDAP syntax OID identifies the
corresponding ASN.1 data type in X.500.  Because without
this relationship, little of LDAP would actually make
sense.

For consider,
   ( 2.5.13.29 NAME 'integerFirstComponentMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

There is zero text in LDAP RFCs which say how to implement
this, but yet there are multiple interoperable implementations
of this matching rule.  Why?  Because 2.5.13.29 is associated
with the X.500 matching rule integerFirstComponentMatch
and 1.3.6.1.4.1.1466.115.121.1.27 is associated with
the ASN.1 date type INTEGER.

While the LDAP specification uses poor mechanism to relate
OIDs with elements of X.500 schema, most implementors have
figured out not only that there are relationships, but
agree to which OID refers to what.  If they didn't agree,
things wouldn't interoperate.

In revising the specification, it's our job to clarify the
specification so that others may repeatedly development
which interoperate.  This will require being a lot clearer
about the relationship between LDAP and X.500.

I will take your above comments as indications of an area
where we need to provide clarification.

Kurt