[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt

To: "'David Chadwick'" <d.w.chadwick@salford.ac.uk>
Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt
From: "Steven Legg" <steven.legg@adacel.com.au>
Date: Tue, 5 Mar 2002 11:31:15 +1100
Cc: <ietf-ldapbis@OpenLDAP.org>
Importance: Normal
In-reply-to: <3C815460.AA76F020@salford.ac.uk>
David,

David Chadwick wrote:
> Steven Legg wrote:
> > 
> > David,
> > 
> > David Chadwick wrote:
> > > 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.
> > 
> > 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.
> > 
> 
> Steven
> 
> we are clearly talking at cross purposes here.

Indeed we are.

> Above, you are only
> talking about the contents of the attribute value (i.e. the V of the
> TLV  encoding). I was talking about the complete BER 
> encoding, including
> the type and length that have to be added to the contents that you are
> describing above.

Okay.

> So, using your examples above, the complete set of
> bytes for the attribute value would be for cn of "foo", 04 03 
> 66 6F 6F,
> and for cn;binary of "foo", 04 05 13 03 66 6F 6F. Hence in both cases
> the OCTET STRING tags CAN be seen. Therefore I believe my text is
> still correct, although clearly not unambiguous as you misinterpreted
> it.

For most users, the contents octets are the value, so describing the BER
encoding as being wrapped up in an OCTET STRING is bound to cause
confusion. Especially since the native encoding is not also described
as being wrapped up in an OCTET STRING.

> 
> I refer you also to Kurt's email, reference:
> 
> Subject: RE: ;binary and userCertificate (Was: Private email ...)
> Date:  Thu, 21 Feb 2002 00:34:25 -0800
> 
> where he quoted the example for a password of FOO, in which the octet
> string wrapper was added in both cases.o

Because the BER encoding of a password *is* an OCTET STRING,
using an OCTET STRING syntax in an example of the effect of ";binary"
is something we should avoid like the plague. It will also lead
to confusion.
 
> 
> 
> > >
> > > 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.
> > 
> > The Certificate syntax does not have a native encoding in LDAPv3.
> 
> It does (or will have) in the new PKIX draft that you are a 
> co-author of
> with myself. I suggest we make it clear that a native encoding is the
> BER or DER encoding of a certificate.
> And as certificates wont be mentioned in LDAPv3 bis documents, this ID
> will become the definitive definition for certificates.

Provided it gets through last call and the IESG unscathed.

> 
> So, I would see that the native encoding of a certificate will start
> with a Type of 10 (sequence) followed by the length of the 
> certificate.
> The ;binary encoding will be the same I believe, but should not be
> mandated.
> I would further suggest that when the PKIX document is
> finished, both transfer syntaxes should be allowed, and will be
> identical.

Defining the native encoding to be the BER encoding of the value
precludes later defining a human-readable representation.

Kurt and I have defined human-readable representations for the
native encodings for the Subtree Specification and ACI Item syntaxes.
Had these syntaxes been originally defined such that the native encoding
was the BER encoding then we would not have been able to define
a human friendly native encoding.

> 
> As an interesting aside, given that ASN.1 is defining XML encoding
> rules, a future version of LDAPv3 might wish to define a ;XML encoding
> for its attribute values!!

We could define a future-proof human-readable representation for
Certificates right now by referencing GSER for the native encoding.

> 
> 
> > 
> > > 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
> > > 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.
> > 
> > The difference is that "certificate" without ";binary" is illegal.
> 
> Only because the native encoding in our ID is not at RFC 
> level yet. But
> once it is, then the native encoding will exist.

Provided consensus is achieved.

Regards,
Steven

> 
> > The native LDAP encoding is, at present, undefined.
> > 
> > > 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.
> > 
> > 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.
> > 
> > >
> > > 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"
> > 
> > No, this suggests an extra OCTET STRING wrapper.
> 
> Agreed. It would be better to say where the embedded octets are 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?
> > 
> > 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."
> > 
> 
> Yes, this is OK.
> 
> David
> 
> > ... with corresponding ASN.1 types nominated for each 
> syntax in RFC 2252bis.
> > 
> > Regards,
> > Steven
> 
> -- 
> *****************************************************************
> 
> 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: D.W.Chadwick@salford.ac.uk
> 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
> 
> *****************************************************************
References:
- Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt
  - From: David Chadwick <d.w.chadwick@salford.ac.uk>
Prev by Date: RE: ASN.1 definitions in draft-ietf-ldapbis-syntaxes-01.txt
Next by Date: RE: ASN.1 definitions in draft-ietf-ldapbis-syntaxes-01.txt
Index(es):
- Chronological
- Thread