Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 25 Feb 2002 11:46:25 +1100

David,

This looks like a good idea. I think the references to octet strings,
though, may imply an additional tag, particularly when you refer to the
OctetStringType.

In view of Steven's recent mail, this may be an opportune time to nail this
down.

I am a bit concerned about

   syntax of the binary value is an ASN.1 data type definition, which is 
   referenced by the "SYNTAX" part of the attribute type definition."

The SYNTAX part refers only to an OID which has not been defined. The only
reference to an ASN.1 structure would have to be the OID of the attribute
type itself, which can be looked up in X.520. I doubt you would find any
reference to 1.3.6.1.4.1.1466.115.121.1.6 (for example) in any X.500
document. Or do you think RFC 2252 should include ASN.1 definitions against
the syntax OIDs?

Thus, I don't see your suggestion as an improvement.

Ron.

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Monday, 25 February 2002 10:18
To: Jim Sermersheim
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt

Jim

I think the new text for attribute descriptions is very good. Much
better than before, especially the description of subtyping. However,
the subsection on Binary Option (4.1.5.1) could still do with some
improvement I feel. Firstly, the section is not as clear as recent email
we have had on the list, explaining that the attribute value, whatever
it is, is treated (or turned into) as an octet string containing BER,
and then a TL octet wrapper is placed around it. 

Secondly, the section talks about overriding the native encoding and
sending it as BER instead. But then your example uses certificates, that
are native BER encoded. So what overriding is there to take place. It
would seem like none, and therefore the effect of ;binary is null. In
other words the section does not clearly indicate to me what the
difference would be in transferring a certificate without ;binary and
one with i.e. certificate;binary.  This is unfortunate and confusing to
the reader. I suggest you use an example that is not a certificate, but
is a simple string. You might then also add text to say what the effect
of ;binary is on a value that is already BER encoded.

I find this sentence particular confusing

"Instead the attribute is to be transferred as 
   a binary value encoded using the Basic Encoding Rules [X.690]."

The reason it is confusing is that all values in BER are binary. So if
the value is already BER what more needs to be done to it? It would seem
nothing.

Perhaps the sentence might read better as

"Instead the attribute value is transferred as an ASN.1 OctetStringType,
where the embedded octet string value is itself a BER encoded value" 

The second sentence
"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."

also has some errors in it, and could then be changed to

"The syntax of the BER encoded value is an ASN.1 data type, which 
must conform to the "SYNTAX" part of the AttributeTypeDescription."

Is that any better?

David

Jim Sermersheim wrote:
> 
> All,
> 
> This revision contains the changes recommended by the attribute options
> engineering team. Please review section 4.1.5 carefully.
> 
> Other changes are listed in section B.7
> 
> Jim
> 
> >>> <[email-masked]> 01/31/02 05:00AM >>>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the LDAP (v3) Revision Working Group of
> the IETF.
> 
>         Title           : Lightweight Directory Access Protocol (v3)
>         Author(s)       : J. Sermersheim
>         Filename        : draft-ietf-ldapbis-protocol-06.txt
>         Pages           : 56
>         Date            : 30-Jan-02
> 
> The protocol described in this document is designed to provide access
> to directories supporting the [X.500] models, while not incurring the
> resource requirements of the X.500 Directory Access Protocol (DAP).
> This protocol is specifically targeted at management applications and
> browser applications that provide read/write interactive access to
> directories. When used with a directory supporting the X.500
> protocols, it is intended to be a complement to the X.500 DAP.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-06.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
> message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-ldapbis-protocol-06.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-ldapbis-protocol-06.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation
> on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

-- 
*****************************************************************

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: "Ramsay, Ron" <[email-masked]>
Date: Mon, 25 Feb 2002 17:46:07 +1100

Steven,

Thanks for the definition.

As you say, audio and jpegPhoto behave correctly, hanks for pointing that
out.

Ron.

-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Monday, 25 February 2002 15:00
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt

Ron,

Ramsay, Ron wrote:
> I've got to resist this notion of the undefined native LDAP encoding.

I originally introduced the term "native LDAP encoding" as a replacement
for "string encoding" because of the confusion "string" causes.
It means the encoding of values one gets when requesting an attribute
without specifying an explicit transfer option (like ";binary").
The native encoding may or may not be a human-readable character string.

> 
> There are only two encodings for an LDAP value (and I think 
> Kurt was saying
> this also):

Yes, the native encoding and the binary encoding.

It would be more correct to say that the LDAP core specification
defines only two transfer encodings. Others may be defined in the
future.

> 
> o The ASN.1 value inherited from the X.500 definition

The binary encoding.

> o Possibly a string definition defined in RFC 2252 (possibly 
> referencing
> other documents - 2253, 1778?)

... which RFC2251bis refers to as the "native encoding".

> 
> If you request an attribute with ;binary, you get the first 
> one. If you
> request a value which has a string encoding, you get the 
> second one. If it
> doesn't have a string encoding, it is probably one of the 
> certificate types
> and the "fix" is to request it with ;binary.

Saying it doesn't have a string encoding is the same as saying
it doesn't have a native LDAP encoding (unless by "string" you
mean a human-readable representation).

> The types audio 
> and jpegPhoto
> are anomalous (if they are their own string encoding (but 
> then, what is a
> string?), they have no ASN.1 definition, so what effect does 
> ;binary have?).

They do have corresponding ASN.1 definitions, but they're hard to
find since the attributes that use them aren't X.500 standard ones.
I eventually tracked down the ASN.1 definitions by inspecting the
Quipu source code. It turns out both syntaxes are treated as
OCTET STRING for X.500 purposes. The effect of ";binary" on these
syntaxes is the same as the effect on the LDAP Octet String syntax.

> so, the certificate syntax has a native encoding but not a 
> string encoding.

It would appear that you are using "string" to mean human-readable
character string. The Certificate syntax certainly doesn't have a
human-readable character string encoding. However, since LDAPv3
doesn't specify what you get if you ask for userCertificate without
";binary", the native encoding is undefined (or if you prefer, the
Certificate syntax doesn't have a native encoding).

> 
> I think it would be fair enough, in the future, to request it without
> ;binary as any LDAP implementor should realise it is binary. 

It wouldn't be fair enough if in future a human-readable character
string encoding is defined, which is what I've done with the ACI Item
syntax.

Regards,
Steven

> There have been
> no complaints about audio or jpegPhoto. ;binary was simply a BAD idea.
> 
> Ron.
> 
> From: Steven Legg [mailto:[email-masked]]
> Sent: Monday, 25 February 2002 12:23
> To: 'David Chadwick'
> Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt
> 
> 
> 
> 
> David,
> 
> David Chadwick wrote:
> This is not the interpretation Kurt and I have been describing. An
> AttributeValue in LDAP is an OCTET STRING. The contents octets of this
> OCTET STRING are either a series of UTF8 encoded characters (being a
> human-readable native LDAP encoding), a series of arbitrary octets
> (being the native LDAP encoding for, e.g., the Octet String syntax -
> 1.3.6.1.4.1.1466.115.121.1.40) or a BER encoded value (comforming to
> the ASN.1 type corresponding to the LDAP syntax).
> There is no extra OCTET STRING wrapper around the BER encoding.
> 
> By way of example, the contents octets of AttributeValue for the value
> "foo" returned as a value of cn would be (in hexadecimal): 66 6F 6F .
> 
> Returned as a value of cn;binary it would be: 13 03 66 6F 6F,
> the BER for a value of the printableString alternative from the
> DirectoryString{} CHOICE. No OCTET STRING tags to be seen.
> 
> >
> > are native BER encoded.
> The Certificate syntax does not have a native encoding in LDAPv3.
> 
> > So what overriding is there to take place. It
> > would seem like none, and therefore the effect of ;binary is null.
> 
> "Overriding" is perhaps the wrong way to describe it, since for some
> syntaxes there is no native LDAP encoding to override. I 
> prefer to think
> of binary as an *alternative* way of encoding a value. For 
> some syntaxes,
> like Certificate, there is no choice because there is only 
> one alternative
> defined.
> 
> > In
> > one with i.e. certificate;binary.
> 
> The difference is that "certificate" without ";binary" is illegal.
> The native LDAP encoding is, at present, undefined.
> 
> > This is unfortunate and
> > confusing to
> RFC 2252 allows a server to store a value in any format it likes.
> If a value is stored as BER then it can be returned in ";binary"
> form without conversion. If stored in the native LDAP encoding
> then to be returned in ";binary" form it must first be re-encoded
> (as BER). The converse applies if the value is requested in native
> LDAP form.
> 
> >
> No, this suggests an extra OCTET STRING wrapper.
> 
> >
> >
> > The second sentence
> > "The
> I would prefer:
> "The value is BER encoded according to the ASN.1 data type
> corresponding to the attribute's LDAP syntax. The LDAP syntax is
> indicated by the "SYNTAX" part of the AttributeTypeDescription."
> 
> ... with corresponding ASN.1 types nominated for each syntax 
> in RFC 2252bis.
> 
> Regards,
> Steven
>