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

RE: New text for X.501

Hi Steven,

I must continue to object.

1) If you use LDAP to chain then we have (for a chained update) LDAP --> X.500 --> LDAP, not X.500 --> LDAP --> X.500!

2) Isn't the postal address escape just '\$'? I don't see the problem with case.

Dumping to LDIF and configuring using LDAP are not X.500-type operations and so require no comment!

Ron

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Steven Legg
Sent: Tuesday, 28 October 2003 15:27
To: Ramsay, Ron
Cc: LDAP BIS
Subject: Re: New text for X.501



Ron,

Ramsay, Ron wrote:
> I must protest that DirectoryString is one of the cases where the
 > abstract value can be preserved. In order to break it you have had
 > to go X.500 -> LDAP -> X.500 and I don't see how this can be justified.
 > LDAP is an access protocol, so we should never have the case to which
 > you referred.

This transformation occurs if an X.500 DSA uses LDIF to dump and reload
data. It also occurs if an X.500 DSA uses LDAP to chain to a subordinate
(LDAP-only) DSA.

> On another matter, does PostalAddress allow spaces either side of the
 > '$'? If it doesn't, then this also is a syntax for which values can be
 > preserved.

The problem with PostalAddress is the need to escape any '$' character
in the abstract value. The escape sequence is case insensitive and could
be case inverted by LDAP -> BER -> LDAP.

> Also, relating to the syntaxes that cannot be preserved, your previous
 > example seemed to concern configuration items like schema. While it may
 > be appropriate to configure LDAP directories using LDAP, I don't know
 > that this should be the case with X.500 directories.

It's a necessity. There are LDAP applications that configure the schema
they need by using LDAP to modify the subschema subentry. Our directory
server let's them do it.

Regards,
Steven

 > However, this still leaves items like SearchGuide.
> 
> Ron
> 
> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Steven Legg
> Sent: Tuesday, 28 October 2003 14:03
> To: David Chadwick
> Cc: LDAP BIS
> Subject: Re: New text for X.501
> 
> 
> 
> David,
> 
> David Chadwick wrote:
> 
>>Steven
>>
>>We are talking about the abstract values and not the encoded values.
>>X.500 does not mandate any particular ASN.1 encoding rules except in the
>>case of the X.509 attributes which must be DER (and even this was later
>>realised to be a bug, but it is too late to change it now). DSAs/LDAP
>>servers will typically store local representations of abstract values
>>and what these are is not stated, its implementation dependent (although
>>in some cases such as the X.509 attributes, they will have to store the
>>encoded values so as to preserve the signatures). Whether the transfer
>>syntax is BER, LDAP or XER should be irrelevant to the abstract value.
>>Does this help to clarify what the intention is
> 
> 
> Yes, though you should be aware that there are cases where even the
> abstract value can't be preserved. The chosen alternative in a DirectoryString
> isn't guaranteed to be preserved in a transformation from BER to LDAP-specific
> to BER. This affects the Directory String syntax, as well as various syntaxes
> that have embedded DirectoryString components. The chosen alternative is
> inconsequential for directory purposes, but changing it is, by strict definition,
> a change to the abstract value.
> 
> Regards,
> Steven
> 
> 
>>regards
>>
>>David
>>
>>
>>Steven Legg wrote:
>>
>>
>>>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
>>>>
>>
>>
> 
> 
> 
> 
>