response controlValue in draft-vchu-ldap-pwd-policy

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

response controlValue in draft-vchu-ldap-pwd-policy

Michael Ströder
HI!

I'm currently looking at how to interpret the correct syntax definition
of the response control value herein:

https://tools.ietf.org/html/draft-vchu-ldap-pwd-policy-00#section-10

Text says:

  controlValue: an octet string: "0",

This could be read as
1. a single byte 48 (ASCII code for digit '0') or
2. an octet string encapsulation a single byte 48 (ASCII code for digit
'0').

I vaguely remember having seen 1. but OpenLDAP recently implemented 2. [1].

I wonder why that control value is needed at all. But that's probably
history...

Ciao, Michael.

_______________________________________________
Ldapext mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ldapext
Reply | Threaded
Open this post in threaded view
|

Re: response controlValue in draft-vchu-ldap-pwd-policy

Neil Wilson-2
I agree that it is ambiguous, but every implementation I have seen has used the former (that is, a single byte of 0x30). I have worked extensively with the Netscape Directory Server in which that control originated, and with its iPlanet and Sun-branded descendants and have never heard of a problem in which a client failed to decode the versions of the controls that they returned. I also

I added support for the password expired and password expiring controls in OpenDS (and the UnboundID and Ping Identity directory servers that descend from it) using the Netscape interpretation. I have never received any reports of any client failing to decode the password expired or password expiring controls that any of these servers return.

I also created and maintain the UnboundID LDAP SDK for Java, which is used to interact with a wide variety of directory servers. It uses this same Netscape interpretation when decoding values for the password expired and password expiring controls. Although it would not be able to decode the value of the password expired or password expiring control if the value was a number wrapped in an octet string, I have never received any reports of that happening.

As such, I think that it is safe to say that the Netscape interpretation (that is, using the raw string representation of the number instead of wrapping it in an octet string) is the de facto standard encoding. It also sounds like the current OpenLDAP implementation is very likely to cause problems.

This is probably a more important issue for the password expiring control (OID 2.16.840.1.113730.3.4.5) defined in the same draft. Its value is actually meaningful, representing the number of seconds until the password expires. Every implementation of the password expiring that I have worked with or created also uses the raw string representation for that number of seconds (for example, if there are 12345 seconds until expiration, the value would be the bytes 0x31, 0x32, 0x33, 0x34, 0x35). While there may be clients that ignore the value of the password expired control, they would be less likely to do so with the password expiring control, and they would be more likely to fail if they encounter those controls with an unexpected value encoding.

Neil


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, July 26, 2020 6:28 AM, Michael Ströder <[hidden email]> wrote:

> HI!
>
> I'm currently looking at how to interpret the correct syntax definition
> of the response control value herein:
>
> https://tools.ietf.org/html/draft-vchu-ldap-pwd-policy-00#section-10
>
> Text says:
>
> controlValue: an octet string: "0",
>
> This could be read as
>
> 1.  a single byte 48 (ASCII code for digit '0') or
> 2.  an octet string encapsulation a single byte 48 (ASCII code for digit
>     '0').
>
>     I vaguely remember having seen 1. but OpenLDAP recently implemented 2. [1].
>
>     I wonder why that control value is needed at all. But that's probably
>     history...
>
>     Ciao, Michael.
>
>
> Ldapext mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ldapext