[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: New text for X.501

Steven,

OK, there is a problem with OIDs. But I don't see any problem with spaces. 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? There would seem little ambiguity if an LDAP directory is dumped to LDIF.

But, yes, object identifies are a problem.

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