RE: New text for X.501

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Yes, you're right.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Monday, 27 October 2003 17:33
To: Ramsay, Ron
Cc: David Chadwick; LDAP BIS
Subject: Re: New text for X.501



Ron,

Ramsay, Ron wrote:
> Steven,
> 
> OK, there is a problem with OIDs. But I don't see any problem with spaces.

I was talking about, for example, Attribute Type Description where there
are optional spaces separating the fields. The number and position of the
spaces gets lost in a transformation from LDAP-specific encoding to BER
encoding.

 > Suppose that an X.500 directory has the required property, that data is
 > always returned in the form it was received. Suppose also that the LDAP
 > interface desires to have the same property. It receives a string value
 > of syntax directoryString. It does not remove any spaces, or change case,
 > but creates the X.500 DirectoryString type using the choice UTF8String.
 > This value is stored without change, according to our assumption. When
 > this value is requested, the X.500 directory supplies this stored value.
 > The LDAP front-end can now extract the string and send it. The client will
 > then receive it exactly as it was provided.
> 
> I don't understand the part about LDIF. You don't intend to dump an X.500
 > directory to an LDIF file, do you?

I chose the LDIF case as a familiar example where the BER -> LDAP-specific -> BER
transformation would occur. The X.500 - LDAP alignment work may have created
other situations where a BER encoding gets turned into an LDAP-specific
encoding which is fetched back as BER. I haven't seen the specification
so I don't know for sure, but if such situations exist then requiring the
preservation of the original encoding is even more dubious.

 > There would seem little ambiguity if an
 > LDAP directory is dumped to LDIF.
> 
> But, yes, object identifies are a problem.

As are optional space separators and case-insensitive labels.
The majority of LDAP syntaxes thwart value preservation in
a mixed environment in one way or another.

Regards,
Steven

> 
> Ron
> 
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@adacel.com.au]
> Sent: Monday, 27 October 2003 15:48
> To: Ramsay, Ron
> Cc: David Chadwick; LDAP BIS
> Subject: Re: New text for X.501
> 
> 
> 
> Ron,
> 
> Ramsay, Ron wrote:
>  > It would be interesting to see which syntaxes can't be preserved.
> 
> Of the syntaxes defined in the syntaxes draft, values of the ones
> prefixed with an asterisk are not guaranteed to be preserved by a
> transformation from the LDAP-specific encoding to the BER encoding and
> back to the LDAP-specific encoding. This is because they allow a variable
> number of spaces, or contain case-insensitive labels, or allow short names
> for OIDs.
> 
> * AttributeTypeDescription
> * Bit String
> * Boolean
>    Country String
> * DeliveryMethod
>    Directory String
> * DIT Content Rule Description
> * DIT Structure Rule Description
> * DN
> * Enhanced Guide
> * Facsimile Telephone Number
>    Fax
>    GeneralizedTime
> * Guide
>    IA5String
>    Integer
>    JPEG
> * LDAP Syntax Description
> * Matching Rule Description
> * Matching Rule Use Description
> * Name and Optional UID
> * Name Form Description
>    Numeric String
> * Object Class Description
>    Octet String
> * OID
>    Other Mailbox
> * Postal Address
>    Printable String
>    Substring Assertion
>    Telephone Number
> * Teletex Terminal Identifier
>    Telex Number
>    UTC Time
> 
> 
> Values of none of the LDAP syntaxes above can be guaranteed to be
> preserved under a transformation from BER to LDAP-specific encoding
> and back to BER (e.g. an LDIF dump and reload) since, in the very least,
> the original BER encoding has a choice of the short form or the long
> form for encoding lengths, and knowledge of this choice is lost in the
> transformation from BER to LDAP-specific encoding.
> 
>  >
>  > Assuming that the access protocol is LDAP, directoryString can be mapped
>  > because X.500 has the UTF8String option. Any LDAP type whose encoding is
>  > ASN.1 can also be mapped. Integers can be mapped.
>  >
>  > PrintableString synataxes seem not to be mappable, except that the
>  > characters should be able to be transcribed as they should already be
>  > printable.
>  >
>  > G3Fax, audio, jpeg all go across as octet string.
>  >
>  > Actually, I would think the only problem would be with data provided from
>  > non-LDAP sources.
>  >
>  > I think it is clear that X.500 can make the requirement.
> 
> It is clear to me that it cannot.
> 
> Regards,
> Steven
> 
>  >
>  > LDAP can make the requirement but servers may not be able to conform to it,
>  > but, from the LDAP perspective, there is nothing to prevent them conforming.
>  >
>  > Ron
>  >
>  > -----Original Message-----
>  > From: owner-ietf-ldapbis@OpenLDAP.org
>  > [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Steven Legg
>  > Sent: Monday, 27 October 2003 10:52
>  > To: David Chadwick
>  > Cc: LDAP BIS; OSIdirectory@az05.bull.com
>  > Subject: Re: New text for X.501
>  >
>  >
>  >
>  > David,
>  >
>  > David Chadwick wrote:
>  >
>  >>Dear LDAPers
>  >>
>  >>At the recent Geneva meeting of the X.500 group, Defect Report 303 was
>  >>discussed. This concerns the fact that a user cannot be guaranteed that
>  >>the information presented to LDAP/X.500 server in an update operation is
>  >>subsequently returned unaltered in a Search operation. Due to this, in
>  >>the PKIX work we are adding text to the IDs specifically to say that for
>  >>X.509 certificates and CRLs the data must not be altered by the LDAP
>  >>server. The X.500 group is going to go one step further than this and
>  >>state that no attributes must be altered by the server and must be
>  >>returned exactly as presented,
>  >
>  >
>  > I think this change is ill-advised, as the requirement cannot be enforced
>  > in a mixed LDAP/X.500 distributed environment. An attribute value that is
>  > entered in an LDAP-specific encoding has to be transformed into BER to be
>  > carried in DSP or DISP. There is no guarantee that the exact LDAP-specific
>  > encoding of the original attribute value will be reconstructed by the
>  > receiving DSA. Preservation of the exact encoding of PKI attributes can
>  > only be made to work in the general case because the LDAP encoding and the
>  > X.500 encoding is the same - BER. For most syntaxes this is not the case.
>  >
>  > The XED specifications introduce a third way of encoding directory data
> (DXER),
>  > which only increases the difficulty of preserving the original encoding.
>  >
>  > If the X.500 standards add this requirement then, as a practical necessity,
>  > I will have to disregard it. However, I will continue to preserve the abstract
>  > value of attribute values to the extent that it is possible to do so.
>  >
>  > Regards,
>  > Steven
>  >
>  >
>  >>although a server may store a
>  >>canonicalised form for efficient matching if it so desires.
>  >>
>  >>The defect report can only address the 1997 and 2001 versions of X.500,
>  >>since the 1993 version that LDAP is based in is no longer supported by
>  >>ITU-T/ISO.
>  >>
>  >>Here is the gist of the proposed text to fix the defect report.
>  >>
>  >>Stored attribute values must be held as supplied. We propose to add text
>  >>to X.501 in clause 8.5 and in 8.8.1, where we will point out that
>  >>rationalizations to stored values for the purposes of matching do not
>  >>effect the stored value. We will also add text to clause 6.1 of x.520
>  >>stating that the rationalizations describe in the matching rules are
>  >>ephemeral, for the purpose of the match only, and will not affect the
>  >>stored value.
>  >>
>  >>Regards
>  >>
>  >>David
>  >>
>  >
>  >
>  >
>  >
>  >
>  >
> 
> 
> 
> 
> 
>