RE: New text for X.501

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

OK

1) DUA --> DSA --> LDAP Server is neither fish-nor-fowl. I see how your customers may want you to do it, but I don't think it has anuthing to do with the current topic.

2) You escape the escape? Far out! How does it apply to the case in hand where clearly the escape is not escaped. That is, the value "street\$name$city" would be stored like this in LDAP and stored as 30 12 0C 0A street$name 0C 04 city in X.500.

Ron
-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Tuesday, 28 October 2003 16:49
To: Ramsay, Ron
Cc: LDAP BIS
Subject: Re: New text for X.501



Ron,

Ramsay, Ron wrote:
> 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!

A DAP modify comes in. The X.500 DSA determines the target entry is in
another DSA (LDAP-only). It chains the modify to the other DSA as an
LDAP modify (X.500 -> LDAP). The other DSA stores the new attribute
values in the LDAP-specific encoding. The user submits a DAP read of
the same target entry. The X.500 DSA chains the read as an LDAP search
to the other DSA, which responds with the attribute values in the
LDAP-specific encoding. The X.500 DSA reformats the attribute values in
BER (LDAP -> X.500) to return to the user.

Overall the values have been through X.500 -> LDAP -> X.500.

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

The escape sequence is \24, but I got the wrong character. The backslash has
to be escaped as well. The escape sequence for *it* is either \5C or \5c.

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

Paying customers don't care about such demarcations.

Regards,
Steven

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