From nobody Sun Jul 26 04:28:44 2020 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB6D3A0DD4 for ; Sun, 26 Jul 2020 04:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD7MekEU06nG for ; Sun, 26 Jul 2020 04:28:38 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2808D3A0DC4 for ; Sun, 26 Jul 2020 04:28:37 -0700 (PDT) Received: from mail1.hv.local (unknown [10.1.1.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail1.stroeder.local", Issuer "stroeder.com Issuing CA 2019-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 1E19256D for ; Sun, 26 Jul 2020 13:28:35 +0200 (CEST) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail1.hv.local (Postfix) with ESMTPS id DC74E3C for ; Sun, 26 Jul 2020 13:28:34 +0200 (CEST) To: ldapext@ietf.org From: =?UTF-8?Q?Michael_Str=c3=b6der?= Autocrypt: addr=michael@stroeder.com; prefer-encrypt=mutual; keydata= mQENBFbdnRoBCADj0vYA4aRwKJ6AE4mf8oElLgMT/1eLNKpJ2FYBWcwj9d8dTk5/p9b8DRxy S/qQIUUZqt9xRFZwUCm0vFeQMRDeN9xzAKoRzrJifoDOacOjG1lhZTKYvVZGgUT89Ao3QeHh Q7gPzcAKNoueoR2y3FXStOYuRrbk5PlSjVAITjsotgc7PWE9mmVYpeu8a+byK/DBHKUyolOA 1UXYvDa7MbPhMtdNm8qnwtKs1Vsyk1VkErM+5cIe+zTT6WYQcmZMRjCtWGiFTzk9W6Mdlskk WRTKhKNgokTsgcy1ecaCBUZWxv/SyXgD81+rwRi9b8Px+1reg43ayxi8sV7jrI1feybbABEB AAG0J01pY2hhZWwgU3Ryw7ZkZXIgPG1pY2hhZWxAc3Ryb2VkZXIuY29tPokBNwQTAQgAIQUC Vt2dGgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRAH3HrjaovJOFpTCACjO773gcmJ KvzjiNpUFl/gANyaJgIq4VbMQ7VthRb1F9X6YbdJ6Z99ntyESjGFCpjofcSomr2vJDpv6ht+ lY33yo20YwsMpqe2OeId0jPybG+FtabKjgBNoAk7iqnBGUvE4t0dz0n1LQVCQR2jxyTKmcNq OYpsRZ3H+6kWwJMuVgsNZglINVZ8JgV5QuLYN5jhYz+pOuFnU11bV6nWREvzZXzebe7g7Zus 6AsWjtJ0lDvgBNzLlF3/eFrVch6Bejs0SvuFseIdZQk+4YU6Rb8xul/jDFXIfo7eTmijO3dV T5AmC1cUi8czncwpgAJnEH8vYv23RoN/aw2gSMCS2huIuQENBFbdnRoBCAC7L1cTVBVZZuM/ yxSUM5CsgGBlTD1Cr7C2ngZFsHSYXVLq6NUB8GZA2iLK96CrwnFw4/Jjz4llOjc50iVRMQKL RyFWOJAMrpPq2ew5T+Uoo524D//dwVbqkFVVuvM8NPiKIDyPGCjP+acM1D8hXwhOXgQ8Iz8Q 3/GRSYjitn9JrkF0ia2nhariznBKVu0LDffxF/hOCx45+QRR2/rYYlshfZMB7nEJX9P+hVfM CSzltz9Z8CldeUbiJvnyrISReR2XBw9oh8JkIUP0BtpIaify9A7EfzOk+W9BUnWe+YwdSUsB fJxOhSv+umyW5GMqZGFu+4oYnkzbe+1LUs1JarCtABEBAAGJAR8EGAEIAAkFAlbdnRoCGwwA CgkQB9x642qLyTjEUgf+JX6Atatl/QKe37yCj1OZYNPd3B0rPLJRF5mEmrADRXLZC9+uFeDS Wxxln040gnR6rjBHrRcvVmlTDiZY26iuL16+V+0/aZ9uyXNQSzk2cwDSiI/8gvr72Y+FN5fh cGXpeNHxHilYc9onzDhxyE76cwzqTKm4q2ULIH2u9IHQ5O86Fv6nHPYhe2fy1bhQapNwi/Xl 3G3i2WNH/w7m+1zWU1IddZOjmXzoxLT1BATwXGa0Tt5RjVb2mM1Wg3Zj6kqFkF2vvKcvrwj0 q0Ap5uyfN5m0uWzQMCMoaV9HQf7f5MkS1lnwBqDgnojjVAieX5uk7olUiRuPKHMfhvXulYP8 AA== Message-ID: <11054c17-5fc7-173f-e571-9d7bbb97cf95@stroeder.com> Date: Sun, 26 Jul 2020 13:28:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [ldapext] response controlValue in draft-vchu-ldap-pwd-policy X-BeenThere: ldapext@ietf.org 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 11:28:41 -0000 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. From nobody Sun Jul 26 08:28:41 2020 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096AD3A0F59 for ; Sun, 26 Jul 2020 08:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ldap.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3-UueHf7OhQ for ; Sun, 26 Jul 2020 08:28:36 -0700 (PDT) Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=ldap.com; 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: "ldapext@ietf.org" Reply-To: Neil Wilson Message-ID: <1qYlIPeNaL0Vfp2vW6aKlqacB21Eu_DJXq8pzo7yFPeT7wfj0FEqvBOx0LG9Z-71-MGuaq_Zz2un_UyWbz0NaCKrmXvP3JtcTLvQqOo6AJM=@ldap.com> In-Reply-To: <11054c17-5fc7-173f-e571-9d7bbb97cf95@stroeder.com> References: <11054c17-5fc7-173f-e571-9d7bbb97cf95@stroeder.com> 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-BeenThere: ldapext@ietf.org 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 wit= h the Netscape Directory Server in which that control originated, and with = its iPlanet and Sun-branded descendants and have never heard of a problem i= n which a client failed to decode the versions of the controls that they re= turned. 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 repor= ts of any client failing to decode the password expired or password expirin= g 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 Net= scape interpretation when decoding values for the password expired and pass= word expiring controls. Although it would not be able to decode the value o= f the password expired or password expiring control if the value was a numb= er wrapped in an octet string, I have never received any reports of that ha= ppening. As such, I think that it is safe to say that the Netscape interpretation (t= hat is, using the raw string representation of the number instead of wrappi= ng 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 actual= ly meaningful, representing the number of seconds until the password expire= s. 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 tha= t ignore the value of the password expired control, they would be less like= ly to do so with the password expiring control, and they would be more like= ly to fail if they encounter those controls with an unexpected value encodi= ng. Neil =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, July 26, 2020 6:28 AM, Michael Str=C3=B6der 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 > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext