Re: [ldapext] response controlValue in draft-vchu-ldap-pwd-policy

Neil Wilson <> Sun, 26 July 2020 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 096AD3A0F59 for <>; Sun, 26 Jul 2020 08:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q3-UueHf7OhQ for <>; Sun, 26 Jul 2020 08:28:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87E563A0F5B for <>; Sun, 26 Jul 2020 08:28:36 -0700 (PDT)
Date: Sun, 26 Jul 2020 15:28:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail2; t=1595777313; bh=j38uz9QRDokcHAVtdS4tq1ZVEXMYjyR8PK5RpkyqoPI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=djbplaGLS4lofFfsogSznYc1RHuWBBeTF8zqOpmJoJmEeU+l/kzy1CwrcSu49sNpA XHQqOsPf73FGw03y5lh3rPxUj5DL4hmGh8Ih9CIy8Z1HywEckmYFf1CLBwTPEQvVw/ dfy3CSWIfFftVTKE+DiHCp9LkkngwBBnW18Rsj7o0gxvjreOHbr+QFCdcMKjQuQY8P 8WXMc5udlxXWJWsR3n+PpU2K4vhQc9Jq4zHy4h6cltJnPzlqCHW8xP+biI64rWyEmx xV3at2msQEC0hMSRC5kFy/v8e3BJA4Zlsm1lXfu76LShqOiP7+RfEx6bgm0HwGiE2v iEkn7yL4Ag9qQ==
To: =?utf-8?Q?Michael_Str=C3=B6der?= <>
From: Neil Wilson <>
Cc: "" <>
Reply-To: Neil Wilson <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [ldapext] response controlValue in draft-vchu-ldap-pwd-policy
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Jul 2020 15:28:39 -0000

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.


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

> HI!
> I'm currently looking at how to interpret the correct syntax definition
> of the response control value herein:
> 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