From michael@stroeder.com Wed Jan 2 07:29:21 2013 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 CA7D121F857C for ; Wed, 2 Jan 2013 07:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKSJmUvO+jhg for ; Wed, 2 Jan 2013 07:29:21 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2021F8574 for ; Wed, 2 Jan 2013 07:29:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id D065760185; Wed, 2 Jan 2013 16:29:15 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOlvNPg0CS_f; Wed, 2 Jan 2013 16:29:10 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 4D058600F7; Wed, 2 Jan 2013 15:29:10 +0000 (UTC) Message-ID: <50E45245.7090008@stroeder.com> Date: Wed, 02 Jan 2013 16:29:09 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Manuel Gaupp References: <50CE24C6.3000006@stroeder.com> <50CE289F.1050908@stroeder.com> <8A8113DD-D03F-4344-B351-673C2AC30B7B@googlemail.com> In-Reply-To: <8A8113DD-D03F-4344-B351-673C2AC30B7B@googlemail.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030500050609090405000805" Cc: "ldap@umich.edu" , ldapext Subject: Re: [ldapext] [ldap] Fwd: New Version Notification for draft-stroeder-namedobject-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 15:29:22 -0000 This is a cryptographically signed message in MIME format. --------------ms030500050609090405000805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Manuel Gaupp wrote: > Michael Str=F6der wrote: >> Please review this draft intended to be published as informational RFC= =2E >=20 > Section 2 ends with the following requirement: >=20 > LDAP clients displaying a list of entries of these object classes > should use mandantory attribute 'cn' to display select lists, hyper-= > links etc. >=20 > I think this requirement is a bit too specific for such generic object > classes. In my opinion, default behavior should be to use the attribute= (s) > from the RDN, any other behavior should depend on the specific use case= =2E=20 I expected this text to provoke some discussion. ;-) But I'd like to encourage deployers to think of sufficiently descriptive common names stored in attribute 'cn' within a given context. Note that 'namedObject' entries are not really usable without auxiliary object clas= s(es) which limit context and thus the meaningful name space for 'cn'. > And, think of multivalued RDNs: "cn=3DnamedPolicyEntry+serialNumber=3D0= 815" and > "cn=3DnamedPolicyEntry+serialNumber=3D4711" would both be listed as > "namedPolicyEntry" according to this requirement. I know that some people use DNs like in your example above to make DNs it= self more readable. But personally I think that multi-valued RDNs really suck because you hav= e to rename an entry in case one of the characteristic attributes change which= is more effort when maintaing data. And I saw too many software components failing to handle them correctly. So one could understand the recommendation in the I-D also to discourage = use of multi-valued RDNs. ;-) > Section 4 contains the following definition: > The OID arc used for the object class defintions is: iso(1) org(3) > dod(6) internet(1) private(4) enter-prise(1) stroeder.com(5427) > objectClasses(6) > This does not match the OIDs used in the object class definitions > (1.3.6.1.4.1.5427.6 versus 1.3.6.1.4.1.5427.1.389.6). Fixed. Thanks! Ciao, Michael. --------------ms030500050609090405000805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTAyMTUyOTA5WjAjBgkq hkiG9w0BCQQxFgQUmvUso/47/peITkGGIEXU6FbPEZowbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAoPbry6Nd0SRT8jaYMQNuSRzNwtF1wKzHFbe4d+ZfPEGKdrrHAEjHFn23lnrxbL3UGuB5 MUZmlqfnlXR+MEEUdIn/cJ51oEAxfyDBm8DpN1148Vx7TacRFnSFIaMD0I4DO6jxRpIuQgDx v/8X0Do4bDmjkDytalSh/4FbO5p/SuQkpS47H1eTwWNaKJCfGcD839avDsSTDJdlvuuOE9/1 5KmSriBMnPsEcXnGoQ13bI7oJp4HVUwYm1SZNMlaGiREG2BD2l3MdBszTjOZqxG0+rVALwD7 9RAfscSmoj0KS/kOJhdwXtJhgJ18Qz6UZu1XmUBstKZ/hAa8TEwYHZ+y+AAAAAAAAA== --------------ms030500050609090405000805-- From andrew.findlay@skills-1st.co.uk Mon Jan 7 04:30:47 2013 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 1EC9B21F84C0 for ; Mon, 7 Jan 2013 04:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8ZkYkRJRurM for ; Mon, 7 Jan 2013 04:30:45 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id A242D21F84BB for ; Mon, 7 Jan 2013 04:30:45 -0800 (PST) Received: from c.9.c.9.0.9.0.3.a.e.d.5.d.e.c.c.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:cced:5dea:3090:9c9c] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TsBs3-0004Zd-Gi; Mon, 07 Jan 2013 12:32:03 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1TsBqn-0008IX-As; Mon, 07 Jan 2013 12:30:45 +0000 Date: Mon, 7 Jan 2013 12:30:45 +0000 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20130107123045.GX5797@slab.skills-1st.co.uk> References: <20121216194204.3327.80452.idtracker@ietfa.amsl.com> <50CE24C6.3000006@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <50CE24C6.3000006@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: ldapext Subject: Re: [ldapext] Fwd: New Version Notification for draft-stroeder-namedobject-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 12:30:47 -0000 On Sun, Dec 16, 2012 at 08:45:10PM +0100, Michael Ströder wrote: > Subject: New Version Notification for draft-stroeder-namedobject-00.txt > This document defines structural object classes that can be used when > no other structural object class seems suitable. Especially the > object classes will give the possibility to associate a common name > and a free-from description with the object. These classes could certainly be useful, but I think the advice attached to them could be improved. In general I find it best to keep meaningful data *out* of DNs. This allows the data in the entry to be updated without changing the DN, which is a very valuable property. I would therefore prefer *not* to use CN as the naming attribute. I propose including uniqueIdentifier as a MUST attribute and strongly suggesting its use as the RDN. I would choose uniqueIdentifier over serialNumber because the latter has a specific meaning that may be required in the objects, whereas the meaning of uniqueIdentifier is 'for local definition' (RFC4524). I would suggest advising the use of opaque values for uniqueIdentifier to make sure that the DN never has to be modified. I realise that using opaque identifiers in DNs makes current LDAP tree browsers rather awkward. I regard this as a user-interface problem that is easily fixed by optionally showing displayName in place of the RDN. Directory designers also have the option of giving uniqueIdentifier the same value as cn or displayName, but that compromises the value of using uniqueIdentifier in the first place. I would support the inclusion of CN because it is commonly used for search. However I would not make it mandatory and I would not suggest its use for displaying select lists etc. CN is potentially multi-valued to support search, so it is not suitable for unambiguous display in lists. displayName should be included in the class and used for that purpose. I normally make displayName mandatory, but that might not be appropriate here given the broad application of these classes. [ Although displayName is SINGLE-VALUE, it does support language tags so any menu built from this attribute can be properly internationalised and localised ]. In schema definition terms, I am suggesting this: ( 1.3.6.1.4.1.5427.1.389.6.20 NAME 'namedObject' SUP top STRUCTURAL MUST ( uniqueIdentifier $ cn ) MAY ( displayName $ description ) ) I have left CN in MUST because the class is called 'namedObject', but would probably be happier if it were in MAY. What about including 'owner' as a MAY attribute? Several of the structural classes in RFC4519 do this, and it is often useful when building access-control policies. If you expect these objects to be used to form drop-down menus or similar human-interface structures, then it may be appropriate to include an attribute specifically to control the ordering. This is getting a bit beyond the original stated purpose though, and is starting to impinge on RFC2293 as well. Perhaps a separate I-D defining an auxiliary class for ordering would be better. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From michael@stroeder.com Mon Jan 7 12:02:19 2013 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 01BFA21F8ACE for ; Mon, 7 Jan 2013 12:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F74IMOYok4rv for ; Mon, 7 Jan 2013 12:02:18 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id D8EB221F8ABA for ; Mon, 7 Jan 2013 12:02:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 62CD1601EF; Mon, 7 Jan 2013 21:02:14 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_6Ls_c45NgD; Mon, 7 Jan 2013 21:02:07 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 0BEC3601A7; Mon, 7 Jan 2013 20:02:07 +0000 (UTC) Message-ID: <50EB29C2.8080601@stroeder.com> Date: Mon, 07 Jan 2013 21:02:10 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Andrew Findlay References: <20121216194204.3327.80452.idtracker@ietfa.amsl.com> <50CE24C6.3000006@stroeder.com> <20130107123045.GX5797@slab.skills-1st.co.uk> In-Reply-To: <20130107123045.GX5797@slab.skills-1st.co.uk> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060403020900050500050607" Cc: ldapext Subject: Re: [ldapext] Fwd: New Version Notification for draft-stroeder-namedobject-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 20:02:19 -0000 This is a cryptographically signed message in MIME format. --------------ms060403020900050500050607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew, thanks for your feedback. Andrew Findlay wrote: > On Sun, Dec 16, 2012 at 08:45:10PM +0100, Michael Str=F6der wrote: >=20 >> Subject: New Version Notification for draft-stroeder-namedobject-00.tx= t >=20 >> This document defines structural object classes that can be used wh= en >> no other structural object class seems suitable. Especially the >> object classes will give the possibility to associate a common name= >> and a free-from description with the object. >=20 > In general I find it best to keep meaningful data *out* of DNs. Me too... > This allows the data in the entry to be updated without changing the > DN, which is a very valuable property.=20 Yupp. > I would therefore prefer *not* > to use CN as the naming attribute. I propose including > uniqueIdentifier as a MUST attribute and strongly suggesting its use > as the RDN. > [..] > I would suggest advising the use of opaque values for > uniqueIdentifier to make sure that the DN never has to be modified. While I strongly agree with the basic idea I won't write it in the I-D li= ke this to preserve backwards-compability with [I-D.howard-namedobject] whic= h is already used in some implementations. (I did not preserve the OID though.= ) > I would choose uniqueIdentifier over serialNumber because > the latter has a specific meaning that may be required in the objects, > whereas the meaning of uniqueIdentifier is 'for local definition' > (RFC4524). I concur. Changed 'serialNumber' to 'uniqueIdentifier'. For the next version of the I-D this text is meant to express a preferenc= e for using 'uniqueIdentifier' over 'cn' to form the RDN: If the optional attribute 'uniqueIdentifier' contains a value it SHOULD be used to form the RDN of the entry. Otherwise the mandantory attribute 'cn' SHOULD be used to form the RDN of the entry if there are no other appropriate naming attributes available. Other attributes allowed by auxiliary classes also MAY be used for naming purposes. Since I'm not a native English speaker suggestions for a better wording a= re very welcome. > I realise that using opaque identifiers in DNs makes current LDAP tree > browsers rather awkward. I regard this as a user-interface problem > that is easily fixed by optionally showing displayName in place of the > RDN. I agree that this is a user-interface problem. And web2ldap handles that pretty well anyway. ;-) But 'displayName' is not really widely used and only defined in RFC 2798.= So I prefer 'cn' over 'displayName' also because of backward-compability to [I-D.howard-namedobject]. But I agree that 'displayName' being SINGLE-VAL= UE is an advantage. > What about including 'owner' as a MAY attribute? Several of the > structural classes in RFC4519 do this, and it is often useful when > building access-control policies. Funny enough I already thought about it. But 'owner' has pretty broad semantics. Therefore I personally don't regard it as suitable for access control and prefer to define custom attributes for it. > If you expect these objects to be used to form drop-down menus or > similar human-interface structures, then it may be appropriate to > include an attribute specifically to control the ordering. This is > getting a bit beyond the original stated purpose though, and is > starting to impinge on RFC2293 as well. I'd like to keep it really simple for now. (Well, you remember what happened to your very simple I-D back in 2007. ;= -) But thanks for your reminder about RFC2293. > Perhaps a separate I-D > defining an auxiliary class for ordering would be better. Looking forward to your I-D specifying it... ;-) Ciao, Michael. --------------ms060403020900050500050607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTA3MjAwMjEwWjAjBgkq hkiG9w0BCQQxFgQUDvpq4gcdXJEH2B/AHp9BwomVsAEwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAGuMWjjXR8QIZYpCQ2tYXVDJitqp5yUTnj9z1xkczcxgSVwpdAEXVNeTgGV/o7wJIbUW3 BH14g6iX15Y9gjxs3Q74SBAM607qeLWXDaUl8ZI/bRouAUDWVgcMhZHYS5uRmCps22kN06Rh ZIvG8g6o/rGbqqq1pNxdLYEldI2aroh4nki8U7kQTJFqAakA9WB4TEUbvhubD0hjGuX5lWRs Z9hPfATGgJyxN2ywLjqZ1LpmR5pg41Dai2b5dzZhjHW+OoPdBDtpZqdXLvdfyPTOnG362ShU ON8InoBIJdej1fQIJIrChkX9zu5OBK9dT4/M3DkqkSXANs8FJZXOlmyQkQAAAAAAAA== --------------ms060403020900050500050607-- From andrew.findlay@skills-1st.co.uk Tue Jan 8 05:18:20 2013 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 124B121F8863 for ; Tue, 8 Jan 2013 05:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9N2J90iDfhl for ; Tue, 8 Jan 2013 05:18:19 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1B421F8751 for ; Tue, 8 Jan 2013 05:18:18 -0800 (PST) Received: from 4.0.a.4.d.d.a.d.c.0.3.9.1.1.5.6.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:6511:930c:dadd:4a04] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TsZ5d-0006rL-Bu; Tue, 08 Jan 2013 13:19:37 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1TsZ4M-0006L7-5m; Tue, 08 Jan 2013 13:18:18 +0000 Date: Tue, 8 Jan 2013 13:18:18 +0000 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20130108131817.GY5797@slab.skills-1st.co.uk> References: <20121216194204.3327.80452.idtracker@ietfa.amsl.com> <50CE24C6.3000006@stroeder.com> <20130107123045.GX5797@slab.skills-1st.co.uk> <50EB29C2.8080601@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <50EB29C2.8080601@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: ldapext Subject: Re: [ldapext] Fwd: New Version Notification for draft-stroeder-namedobject-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 13:18:20 -0000 On Mon, Jan 07, 2013 at 09:02:10PM +0100, Michael Ströder wrote: > > I would therefore prefer *not* > > to use CN as the naming attribute. I propose including > > uniqueIdentifier as a MUST attribute and strongly suggesting its use > > as the RDN. > > [..] > > I would suggest advising the use of opaque values for > > uniqueIdentifier to make sure that the DN never has to be modified. > > While I strongly agree with the basic idea I won't write it in the I-D like > this to preserve backwards-compability with [I-D.howard-namedobject] which is > already used in some implementations. (I did not preserve the OID though.) The original I-D made CN mandatory in the text but optional in the schema definition. Looking around for things that use namedObject, I found: 1 SuSE's YaST version of the RFC2307bis schema where they apparently use namedObject for empty groups and then change the object class to groupOfNames when the group gets a member! 2 ForgeRock inculude the I-D.howard-namedobject definition in their core schema 3 OpenLDAP does not ever seem to have distributed a definition for this class 4 Gosa includes exactly the same RFC2307bis schema that SuSE uses. 5 Kolab seems to have an incompatible derivative using the original OID and a new name: olcObjectClasses: ( 1.3.6.1.4.1.5322.13.1.1 NAME 'kolabNamedObject' SUP top STRUCTURAL MAY (cn $ ou) ) There is at least one other definition of namedObject floating around though I don't know whether it has ever been used: http://tools.ietf.org/id/draft-furuseth-ldap-untypedobject-02.txt That one permits a wide range of attributes but expects you to use just one of them in the entry. If we assume that only the I-D.howard-namedobject version is actually used in the wild, then one option for preserving compatibility would be: ( 1.3.6.1.4.1.5427.1.389.6.20 NAME 'namedObject' SUP top STRUCTURAL MAY ( uniqueIdentifier $ cn $ displayName $ description ) ) > For the next version of the I-D this text is meant to express a preference for > using 'uniqueIdentifier' over 'cn' to form the RDN: > > If the optional attribute 'uniqueIdentifier' contains a value it > SHOULD be used to form the RDN of the entry. Perhaps add: There are advantages to using opaque (meaningless) values in the RDN of the entry, as this allows all meaningful attributes to be modified without changing the RDN. > Otherwise the mandantory attribute 'cn' SHOULD be used to form > the RDN of the entry if there are no other appropriate naming > attributes available. > Other attributes allowed by auxiliary classes also MAY be used for > naming purposes. This would still permit the traditional use of the objectclass, but would provide a pointer towards better design practice. > But 'displayName' is not really widely used and only defined in RFC 2798. So I > prefer 'cn' over 'displayName' also because of backward-compability to > [I-D.howard-namedobject]. But I agree that 'displayName' being SINGLE-VALUE is > an advantage. RFC2798 defines inetOrgPerson, so displayName is almost certain to be available in every deployed LDAP server. The only objection that I can see is that the attribute description refers to 'a person': ( 2.16.840.1.113730.3.1.241 NAME 'displayName' DESC 'preferred name of a person to be used when displaying entries' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) I have used displayName for years in all sorts of entries because its purpose and usage is very clear. I am not sure that it is necessary to say anything about how to display lists of items, but if you want to keep that in, how about: LDAP clients displaying entries of these object classes SHOULD take the title of the entry from the displayName attribute if available, otherwise from the cn or other appropriate attribute. The value of the uniqueIdentifier attribute will not usually be useful to a human user. > > Perhaps a separate I-D > > defining an auxiliary class for ordering would be better. > > Looking forward to your I-D specifying it... ;-) I will give it some thought! Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From linus@vangeuns.name Wed Jan 9 07:33:59 2013 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 00BBE21F8614 for ; Wed, 9 Jan 2013 07:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOFH3Q8GH7S3 for ; Wed, 9 Jan 2013 07:33:58 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA2021F8615 for ; Wed, 9 Jan 2013 07:33:57 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so1676372vba.27 for ; Wed, 09 Jan 2013 07:33:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6zI0nM45HEL5+Eaqvuo+f5qklJSMbFI5QyPVwSMjyhc=; b=mm7IWqSJ1u+xDqbRGAJOUMO+TE8L2QzFv72BGDBS7evU1rAsdMIZDw5UhvLbjVA7Bx t1DZCptMjkr0nS0UXmTevZ/AJw2U+GjasF0S6vQ4Uv4CsZpiyH3y0zjmJXkOUIdfRkoy 65MQOEzob0NT5at3U1z3/EEyJxcXVb7/pCe4UV+EwUW/MVFV2jKCQxWyE97FwiirRyUc L6Xh3JXu24VQULbNGE00f4qdE350TVl7IphCSQ7dCzP7U/FjTL5zbeWiOxLAe42NCvst dKWxcTfxKjxBlHUSfilbobTCHfrP8rhRdfFIMMq9Gl+bQDwNFveQLK6U0qOYh8p93bnm ZbYQ== MIME-Version: 1.0 Received: by 10.220.151.83 with SMTP id b19mr87954957vcw.25.1357745637236; Wed, 09 Jan 2013 07:33:57 -0800 (PST) Received: by 10.52.72.105 with HTTP; Wed, 9 Jan 2013 07:33:57 -0800 (PST) Received: by 10.52.72.105 with HTTP; Wed, 9 Jan 2013 07:33:57 -0800 (PST) In-Reply-To: <50E45245.7090008@stroeder.com> References: <50CE24C6.3000006@stroeder.com> <50CE289F.1050908@stroeder.com> <8A8113DD-D03F-4344-B351-673C2AC30B7B@googlemail.com> <50E45245.7090008@stroeder.com> Date: Wed, 9 Jan 2013 16:33:57 +0100 Message-ID: From: Linus van Geuns To: =?UTF-8?Q?Michael_Str=C3=B6der?= Content-Type: multipart/alternative; boundary=f46d0434bf1e671e4004d2dccae8 X-Gm-Message-State: ALoCoQmxCDqr2wGhXwadu+ekd4zdD5+fyvyAR+xIlpzQgEBEOUtISnrWwh8PR15aHy6OzbGEFEay X-Mailman-Approved-At: Wed, 09 Jan 2013 11:07:21 -0800 Cc: LDAP Mailing List Michigan , ldapext Subject: Re: [ldapext] [ldap] Re: Fwd: New Version Notification for draft-stroeder-namedobject-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:37:37 -0000 --f46d0434bf1e671e4004d2dccae8 Content-Type: text/plain; charset=UTF-8 Hey Michael, Your draft (draft-stroeder-namedobject-01) basically defines a common, structural object class to be combined with arbitrary auxiliary classes established e.g. in other standards. This could drastically reduce the number of structural ('non-combinable') object classes defined for public use. This in turn might reduce the number of custom classes to combine several structural classes from public schema definitions. I did not yet find any satisfactory rationale for specifying the kind of a class within the object class definition anyways. IMHO, the structural object class of an entry - if required at all - should be defined during instantiation of that particular entry and may be governed by structure rules. Since LDAPv3 is the current and proposed standard, I think your proposal is the best approach we have regarding that issue. As attribute 'cn' is multi-valued and ambiguous entry names in user-interfaces are pretty annoying, I would like to restrict your recommendation on string-representation of entries in chapter 2 as well. In case that any value of mandatory attribute 'cn' is used to form the RDN of an entry of these object classes, LDAP-clients SHOULD use that distinguished value for string-representation of the particular entry (e.g. within user interfaces). Any additional AVAs present in such a RDN SHOULD also be included in the entries string-representation, indicating the attribute type of each additional value. As this recommendation is pretty generic, it might fit in more smoothly into a more generic LDAP client BCP. :o) Regarding to your rationale for class 'namedPolicy' in chapter 2.2: I dont understand how combining policy-related auxiliary classes with class 'namedObject' would restrict this class in any way. Regards, Linus --f46d0434bf1e671e4004d2dccae8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hey Michael,

Your draft (draft-stroeder-namedobject-01) basically defines= a common, structural object class to be combined with arbitrary auxiliary = classes established e.g. in other standards.
This could drastically reduce the number of structural ('non-combinable= ') object classes defined for public use. This in turn might reduce the= number of custom classes to combine several structural classes from public= schema definitions.

I did not yet find any satisfactory rationale for specifying= the kind of a class within the object class definition anyways. IMHO, the = structural object class of an entry - if required at all - should be define= d during instantiation of that particular entry and may be governed by stru= cture rules.

Since LDAPv3 is the current and proposed standard, I think y= our proposal is the best approach we have regarding that issue.

As attribute 'cn' is multi-valued and ambiguous entr= y names in user-interfaces are pretty annoying, I would like to restrict yo= ur recommendation on string-representation of entries in chapter 2 as well.=

<proposal >
In case that any value of mandatory attribute 'cn' is used to form = the RDN of an entry of these object classes, LDAP-clients SHOULD use that d= istinguished value for string-representation of the particular entry (e.g. = within user interfaces). Any additional AVAs present in such a RDN SHOULD a= lso be included in the entries string-representation, indicating the attrib= ute type of each additional value.
</proposal>

As this recommendation is pretty generic, it might fit in mo= re smoothly into a more generic LDAP client BCP. :o)

Regarding to your rationale for class 'namedPolicy' = in chapter 2.2:
I dont understand how combining policy-related auxiliary classes with class= 'namedObject' would restrict this class in any way.

Regards, Linus

--f46d0434bf1e671e4004d2dccae8-- From michael@stroeder.com Sat Jan 26 07:41:33 2013 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 1A21621F8721 for ; Sat, 26 Jan 2013 07:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wttaAch7OGsG for ; Sat, 26 Jan 2013 07:41:31 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE9D21F871D for ; Sat, 26 Jan 2013 07:41:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 7C711602A6; Sat, 26 Jan 2013 16:41:28 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE8DWbT8veQK; Sat, 26 Jan 2013 16:41:25 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 014C56017F; Sat, 26 Jan 2013 15:41:24 +0000 (UTC) Message-ID: <5103F924.2070800@stroeder.com> Date: Sat, 26 Jan 2013 16:41:24 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.1 MIME-Version: 1.0 To: ldapext , "ldap@umich.edu" X-Enigmail-Version: 1.5 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040102040804000703090903" Subject: [ldapext] Any implementations using userPassword;hash-scheme? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ldapext List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 15:41:33 -0000 This is a cryptographically signed message in MIME format. --------------ms040102040804000703090903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI! Is anyone here aware of any implementation using userPassword;hash-scheme= ? It was described in RFC 2307 but starting with a rather vague text: "A future standard may specify LDAP v3 attribute descriptions to represen= t hashed userPasswords" The text was already dropped in draft-howard-rfc2307bis-02 section 5.2.2.= 1. but without any further explanation. So I guess there are no implementations but I want to make sure. Ciao, Michael. --------------ms040102040804000703090903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTI2MTU0MTI0WjAjBgkq hkiG9w0BCQQxFgQU8DQ+Fk0d/NeiI2y09mbbXuwd/QYwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAfXzPrz1ScjnVI4+BVoPy41J68G4WMFVa2cnKWHziBZJIWLnQoS9puekZQosfHTVfaxM0 WLcoLJWiEzmw0GEbWC9x4gjFqHxv1LyvU1YX0IGEAD7i0zW87K46VXJAOjSw/aA1rEQ80z59 ITpvV4lUZY/VM2CdatwqU13jG2LYMMqTMRNixd0pT1xvFuNGK1DYy66spylBYoXmmC8bgAcQ +Q32UI1IKnuRcPDw2QwUmT7K+iv6OWXxpA918J58+t1wPaD+/iVxc9PEF+nU72laxraayNxP S+SX3Gnr8lZRWnQF+QN1C5eW06Uusc73nhem6O56dX8cQixm26G8rH/6kQAAAAAAAA== --------------ms040102040804000703090903-- From msgong@us.ibm.com Sat Jan 26 09:04:19 2013 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 B618821F84ED for ; Sat, 26 Jan 2013 09:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szZOOL9FmNfC for ; Sat, 26 Jan 2013 09:04:19 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id 0B68F21F84D9 for ; Sat, 26 Jan 2013 09:04:18 -0800 (PST) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 26 Jan 2013 10:04:18 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 26 Jan 2013 10:04:15 -0700 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 78DEE3E40026 for ; Sat, 26 Jan 2013 10:04:08 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0QH4EUW252266 for ; Sat, 26 Jan 2013 10:04:14 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0QH4DBJ020095 for ; Sat, 26 Jan 2013 10:04:13 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.63.40.225]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0QH4BM2019990 for ; Sat, 26 Jan 2013 10:04:11 -0700 Auto-Submitted: auto-generated From: Mike Gong To: ldapext Message-ID: Date: Sat, 26 Jan 2013 10:04:09 -0700 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF2|October 8, 2012) at 01/26/2013 10:04:11 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF06CDFCE45218f9e8a93df938690918c08BBF06CDFCE4521" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13012617-4834-0000-0000-00000301FE58 Subject: [ldapext] AUTO: Mike Gong is on vacation (returning 02/02/2013) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 17:04:19 -0000 --0__=08BBF06CDFCE45218f9e8a93df938690918c08BBF06CDFCE4521 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 02/02/2013. I will have only limited access to email. For immediate assistance, please contact my manager Bradley Olive or my= team lead John Sullivan Note: This is an automated response to your message "[ldapext] Any implementations using userPassword;hash-scheme?" sent on 01/26/2013 8:4= 1:24 . This is the only notification you will receive while this person is awa= y.= --0__=08BBF06CDFCE45218f9e8a93df938690918c08BBF06CDFCE4521 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 02= /02/2013.

I will have only limited ac= cess to email.
For immediate assistance, p= lease contact my manager Bradley Olive or my team lead John Sullivan

Note: Thi= s is an automated response to your message  "[ldapext] Any implementations using user= Password;hash-scheme?" sent on 01/26/2013 8:41:24.

This is t= he only notification you will receive while this person is away.= = --0__=08BBF06CDFCE45218f9e8a93df938690918c08BBF06CDFCE4521-- From lukeh@padl.com Sat Jan 26 19:24:15 2013 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 29E3821F88FB for ; Sat, 26 Jan 2013 19:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD01f+IUodCY for ; Sat, 26 Jan 2013 19:24:14 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1906F21F88B5 for ; Sat, 26 Jan 2013 19:24:13 -0800 (PST) Received: by us.padl.com with ESMTP id r0R3O9GF001970; Sat, 26 Jan 2013 22:24:11 -0500 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <5103F924.2070800@stroeder.com> Date: Sun, 27 Jan 2013 14:24:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <406C5DCE-CA6D-4E1C-BC00-2A89C9ACCF3B@padl.com> References: <5103F924.2070800@stroeder.com> To: ldapext X-Mailer: Apple Mail (2.1499) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "ldap@umich.edu" Subject: Re: [ldapext] Any implementations using userPassword;hash-scheme? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 03:24:15 -0000 I don't think you're going to find anything that uses this. nss_ldap = supported authPassword as a compile-time option but, looking through the = revision history, I can't find anything referring to attribute = descriptions. -- Luke On 27/01/2013, at 2:41 AM, Michael Str=F6der = wrote: > HI! >=20 > Is anyone here aware of any implementation using = userPassword;hash-scheme? >=20 > It was described in RFC 2307 but starting with a rather vague text: > "A future standard may specify LDAP v3 attribute descriptions to = represent > hashed userPasswords" >=20 > The text was already dropped in draft-howard-rfc2307bis-02 section = 5.2.2.1. > but without any further explanation. >=20 > So I guess there are no implementations but I want to make sure. >=20 > Ciao, Michael. >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From michael@stroeder.com Mon Jan 28 12:46:47 2013 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 B393C21F8726 for ; Mon, 28 Jan 2013 12:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBSgmvCw5woU for ; Mon, 28 Jan 2013 12:46:47 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id A8D4621F86EC for ; Mon, 28 Jan 2013 12:46:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id CCD64601B5 for ; Mon, 28 Jan 2013 21:46:44 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPuS-EQuXCz6 for ; Mon, 28 Jan 2013 21:46:37 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id A62516018A for ; Mon, 28 Jan 2013 20:46:37 +0000 (UTC) Message-ID: <5106E3AD.3010900@stroeder.com> Date: Mon, 28 Jan 2013 21:46:37 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.1 MIME-Version: 1.0 To: ldapext References: <20130128204404.7501.43637.idtracker@ietfa.amsl.com> In-Reply-To: <20130128204404.7501.43637.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130128204404.7501.43637.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000509020506060605050604" Subject: [ldapext] Fwd: New Version Notification for draft-stroeder-hashed-userpassword-values-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 20:46:47 -0000 This is a cryptographically signed message in MIME format. --------------ms000509020506060605050604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI! Please review this draft intended to be published as informational RFC. Ciao, Michael. -------- Original Message -------- Subject: New Version Notification for draft-stroeder-hashed-userpassword-values-00.txt Date: Mon, 28 Jan 2013 12:44:04 -0800 From: internet-drafts@ietf.org To: michael@stroeder.com A new version of I-D, draft-stroeder-hashed-userpassword-values-00.txt has been successfully submitted by Michael Stroeder and posted to the IETF repository. Filename: draft-stroeder-hashed-userpassword-values Revision: 00 Title: Lightweight Directory Access Protocol (LDAP): Hashed Attribute v= alues for 'userPassword' Creation date: 2013-01-28 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-va= lues-00.txt Status: http://datatracker.ietf.org/doc/draft-stroeder-hashed-userpassword-values= Htmlized: http://tools.ietf.org/html/draft-stroeder-hashed-userpassword-values-00 Abstract: This document describes the widely used syntax for storing hashed passwords in LDAP attribute 'userPassword' and extends its use for SHA-2 hash algorithms. Furthermore it points out some of the deficiencies of that approach. The IETF Secretariat --------------ms000509020506060605050604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTI4MjA0NjM3WjAjBgkq hkiG9w0BCQQxFgQUG59U1uorp3QqR2JGjbx38daD4iswbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEArQ+OShkhGKsQ/40LpP+NgqOtp22QuMKz78DhE2T+wto9ncfgFJPv1p+kpeDsxxYbs0XB UdCtb4zzShacwAd0f9pxBTTnMRdKONWUlAddLVWgzb8nnbwNgc/N7CdI8AC+mmeA+G6GxqOg ed7+lAgx20g7pvZAMYAEw+hFjdXe4u4l1CBJTb/Fnalqqfdo5wq4NZrfMX8LkzRYTF9qecv4 GtLJzdZjdbzbAgzrcTdoWHF+y65X6SW8FXsWM4aLoAhd/U2+5kQiyPqcI+sLZdawyFwaDWn2 2GffUzf2hGKeVjE4CUDCemoh7rYbUixBQB1V6WGpWsW1M9p0W/FGIzibmwAAAAAAAA== --------------ms000509020506060605050604-- From andrew.sciberras@eb2bcom.com Mon Jan 28 16:22:20 2013 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 612CF21E8044 for ; Mon, 28 Jan 2013 16:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUGzEqzBpk5Y for ; Mon, 28 Jan 2013 16:22:18 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BCA4321E8039 for ; Mon, 28 Jan 2013 16:22:16 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id j4so1694442bkw.17 for ; Mon, 28 Jan 2013 16:22:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=AFlIiDNBiHrp46FQv2jHUsEb8NaSpOvFoyFvdDzyHEQ=; b=nKr5wgda8049IcqWDbIIse0GvzBv+SuyBpjfUfii/ji9gRIjNcyd9+StM8h7LQiX6C CtLhsN070TZEdCK1tTBAvmZU2zSl0r62b2/pKQs60xzU8QBz1EgFGm9ESEG4AQWcPsnJ hvYOsP0BD6KIO7GkJZkq5QZW8r2jln1BdpFF9+ikCH9t1tYhJQJR2JcvXCYim1g45DFk D7zKzE7W5gNZRuvyk38Wz2ubqCgLLhGeIMJX2/iVJ1HPKqzDKo7tqKzPXcUV1ypGais1 bW1D9KYKV8XjKhfm7dNQcvc8U8//EJYiyKMlwf09X0NTGaqUfgJLB9i8mNCmGNQx91CC sAzg== MIME-Version: 1.0 X-Received: by 10.204.145.152 with SMTP id d24mr4512205bkv.41.1359418935602; Mon, 28 Jan 2013 16:22:15 -0800 (PST) Received: by 10.204.157.2 with HTTP; Mon, 28 Jan 2013 16:22:15 -0800 (PST) In-Reply-To: <5103F924.2070800@stroeder.com> References: <5103F924.2070800@stroeder.com> Date: Tue, 29 Jan 2013 11:22:15 +1100 Message-ID: From: Andrew Sciberras To: ldapext Content-Type: multipart/alternative; boundary=0015175cf9e8c1f01604d46262bc X-Gm-Message-State: ALoCoQkzNoCxsQzEAxT3z3D+MCJQv/V+98H+jQUroD27A+1hXsbuaOFZwvnMzHda0Mch34+5KAwY Cc: "ldap@umich.edu" Subject: Re: [ldapext] Any implementations using userPassword;hash-scheme? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 00:22:20 -0000 --0015175cf9e8c1f01604d46262bc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael Yes, the ViewDS product does support attribute value hashing using attribute options to convey the hash scheme. Andrew On Sun, Jan 27, 2013 at 2:41 AM, Michael Str=F6der wr= ote: > HI! > > Is anyone here aware of any implementation using userPassword;hash-scheme= ? > > It was described in RFC 2307 but starting with a rather vague text: > "A future standard may specify LDAP v3 attribute descriptions to represen= t > hashed userPasswords" > > The text was already dropped in draft-howard-rfc2307bis-02 section 5.2.2.= 1. > but without any further explanation. > > So I guess there are no implementations but I want to make sure. > > Ciao, Michael. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > > --=20 *Andrew Sciberras CISSP *Managing Consultant Suite 1, 85 - 87 Charles St, Kew 3101 VIC *t *+61 3 9851 8633 *e * andrew.sciberras@eb2bcom.com *w *www.eb2bcom.com *ln *LinkedIn --0015175cf9e8c1f01604d46262bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Michael

Yes, the ViewDS product does= support attribute value hashing using attribute options to convey the hash= scheme.=A0

Andrew=A0


On Sun, Jan 27, 2013 at 2:41 AM, Michael= Str=F6der <michael@stroeder.com> wrote:
HI!

Is anyone here aware of any implementation using userPassword;hash-scheme?<= br>
It was described in RFC 2307 but starting with a rather vague text:
"A future standard may specify LDAP v3 attribute descriptions to repre= sent
hashed userPasswords"

The text was already dropped in draft-howard-rfc2307bis-02 section 5.2.2.1.=
but without any further explanation.

So I guess there are no implementations but I want to make sure.

Ciao, Michael.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext




--

Andrew Sciberras CISSP
Managing Consultant

Suite 1, 85 - 87 Charles St, Kew 3101 VIC

t=A0+61 3 9851 8633
e=A0 andrew.sciberras@eb2bcom.com=A0
w www.eb2bcom.com
ln=A0LinkedIn


=A0

--0015175cf9e8c1f01604d46262bc-- From michael@stroeder.com Tue Jan 29 00:05:03 2013 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 B66F921F89E1 for ; Tue, 29 Jan 2013 00:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blnB+q8fEDjk for ; Tue, 29 Jan 2013 00:05:03 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id A349921F890E for ; Tue, 29 Jan 2013 00:05:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 1A0B96020E; Tue, 29 Jan 2013 09:05:00 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn7E7kz0pM_7; Tue, 29 Jan 2013 09:04:56 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 9909F6018A; Tue, 29 Jan 2013 08:04:55 +0000 (UTC) Message-ID: <510782A6.7050209@stroeder.com> Date: Tue, 29 Jan 2013 09:04:54 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.1 MIME-Version: 1.0 To: Andrew Sciberras References: <5103F924.2070800@stroeder.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010307050600020805030205" Cc: "ldap@umich.edu" , ldapext Subject: Re: [ldapext] Any implementations using userPassword;hash-scheme? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 08:05:03 -0000 This is a cryptographically signed message in MIME format. --------------ms010307050600020805030205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Sciberras wrote: > Yes, the ViewDS product does support attribute value hashing using attr= ibute > options to convey the hash scheme.=20 Ok, I will extend the spec described in draft-stroeder-hashed-userpassword-values in the next revision. Ciao, Michael. > On Sun, Jan 27, 2013 at 2:41 AM, Michael Str=F6der > wrote: >=20 > HI! >=20 > Is anyone here aware of any implementation using userPassword;hash-= scheme? >=20 > It was described in RFC 2307 but starting with a rather vague text:= > "A future standard may specify LDAP v3 attribute descriptions to re= present > hashed userPasswords" >=20 > The text was already dropped in draft-howard-rfc2307bis-02 section = 5.2.2.1. > but without any further explanation. >=20 > So I guess there are no implementations but I want to make sure. >=20 > Ciao, Michael. --------------ms010307050600020805030205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTI5MDgwNDU0WjAjBgkq hkiG9w0BCQQxFgQUXCSylJMwTMbmu4EAjATgt5QJNt8wbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAGSY4vtes0DrYE8s4FQG9vIeyo69Vl1f+By8wuBwRNa3vgBRfawpHWYD/TVSF5onIdDt9 u38a5EljIWDP0ogfw1Yh64iracbsmJwhmryFHk9I5sAS7aN/aYLL0m7PExNALdYjby6smFVc 3En9sRD0E8iVIlAGT9Fs9dhyo7aLwnKTS5DbSA43h0lc1jF+HOltS3nmvFaU9geWFkardJx/ i6+HfqR6KL+/HbveOOxSVs0XGA9oYuYDKSblc4I1s0xXCEb7GkL3pGXenjNafuqs0GKXxWzx c9uDMgdm7RnsNAGsFyPvWdSJMpdsyqHNuwfSl9Q1sRb6iIu1E88spEyv/AAAAAAAAA== --------------ms010307050600020805030205-- From kurt.zeilenga@isode.com Tue Jan 29 03:18:58 2013 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 1E82021F8863 for ; Tue, 29 Jan 2013 03:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5gb4lJPyjCe for ; Tue, 29 Jan 2013 03:18:57 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id C869521F8834 for ; Tue, 29 Jan 2013 03:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1359458325; d=isode.com; s=selector; i=@isode.com; bh=DK+0zhKZ/zpKT3EkHrCSTp4SWoaW7hei9wkYzlMiZR0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=BrD38pXCsc7xb2G6tp1IP4HKar8F1/BoT7bW/hFdrbxKbTLFwQWnZPJ+6XXp5iADYvkCFB 3H6HhhMOdG8cNUrw80an2x/lpp38dxFORNMv+ou2CPowVI7pTcYjMBbuZyp7t0x2JL8qCF a8NLa76RwIlyPXcPx2ixK64UNbAK12c=; Received: from pagan.boolean.net (66-214-104-34.dhcp.slto.ca.charter.com [66.214.104.34]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 29 Jan 2013 11:18:45 +0000 From: Kurt Zeilenga In-Reply-To: <510782A6.7050209@stroeder.com> Date: Tue, 29 Jan 2013 03:18:34 -0800 Message-Id: <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> To: =?iso-8859-1?Q?Michael_Str=F6der?= X-Mailer: Apple Mail (2.1499) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Andrew Sciberras , "ldap@umich.edu" , ldapext Subject: Re: [ldapext] Any implementations using userPassword;hash-scheme? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 11:18:58 -0000 On Jan 29, 2013, at 12:04 AM, Michael Str=F6der = wrote: > Andrew Sciberras wrote: >> Yes, the ViewDS product does support attribute value hashing using = attribute >> options to convey the hash scheme.=20 >=20 > Ok, I will extend the spec described in > draft-stroeder-hashed-userpassword-values > in the next revision. In writing an I-D for publication as an RFC, there a few options: 1) Standard Track 2) Informational 3) Experimental The second two allow for independent submission (directly to the RFC = Editor, don't require IETF consensus, but do require IESG no-objection = (aimed at detecting trying to run a "standard" around the IETF)). For this particular specification, given past experiences in the IETF = LDAP WGs and userPassword, I suspect you'll run into standardization = issues. Even if the IETF wanted to extend userPassword (which is = questionable), the IETF doesn't own the specification of userPassword in = the Directory. That's owned by the ISO/ITU X.500 committee. So = changes/extensions to userPassword ought to be taken there, not to the = IETF. Experimental is for, well experiments. Though 2307 was an experiment, I = think we can say that experiment should be concluded. One could have = this I-D conclude the part about userPassword. And informational would = be an appropriate track to do especially since given the above = userPassword standardization issue. Informational is also a very good track on stating what current practice = is. In addition to providing a specification of that practice (which = should note differences seen in the wild, especially those impacting = interoperability), it should talk about other issues, such as = interoperability issues with implementations adhering to the standard = specifications (here the standard userPassword specification). I think = security issues are important to discuss here (a bit on that in a = second). I see this document is marked as being intended to be published as = Informational, but it reads more like it's trying to be a standard. I = think trying to standardize this will not go far, so I suggest you take = a 'document current practice' approach here (make it clear in the = abstract and intro that's what the purpose of the document is, and then = fulfill that purpose throughout the document). Gold star if you = conclude the 2307 experiment, at least in the userPassword area. Security Considerations: I think that it should be made clear that all = of these schemes in the doc are quite prone to dictionary and brute = force attack. The viability of these attacks is not generally impacted = by the length of the hash but by rate in which the attacker produce a = value from an input. (Salted variants hinders pre-computed dictionary = attacks.) I note that at Isode we have a 2307 style hash scheme that we use to = hold SCRAM compatible hash. Aside from being SCRAM compatible, it's = designed to hinder dictionary and brute force attacks by significant = increasing the cost of producing the stored value. It would be good to = include this as part of the 'current practice'. -- Kurt >=20 > Ciao, Michael. >=20 >> On Sun, Jan 27, 2013 at 2:41 AM, Michael Str=F6der = > > wrote: >>=20 >> HI! >>=20 >> Is anyone here aware of any implementation using = userPassword;hash-scheme? >>=20 >> It was described in RFC 2307 but starting with a rather vague = text: >> "A future standard may specify LDAP v3 attribute descriptions to = represent >> hashed userPasswords" >>=20 >> The text was already dropped in draft-howard-rfc2307bis-02 section = 5.2.2.1. >> but without any further explanation. >>=20 >> So I guess there are no implementations but I want to make sure. >>=20 >> Ciao, Michael. >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From michael@stroeder.com Tue Jan 29 13:22:39 2013 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 ACCD821F8726 for ; Tue, 29 Jan 2013 13:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT-N6WPULpGt for ; Tue, 29 Jan 2013 13:22:39 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5BECB21F871E for ; Tue, 29 Jan 2013 13:22:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 092FE60225; Tue, 29 Jan 2013 22:22:36 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXjmnA6P4ufG; Tue, 29 Jan 2013 22:22:27 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 8A39C6018A; Tue, 29 Jan 2013 21:22:26 +0000 (UTC) Message-ID: <51083D91.30205@stroeder.com> Date: Tue, 29 Jan 2013 22:22:25 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> In-Reply-To: <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000107040603060309030103" Cc: ldapext Subject: [ldapext] draft-stroeder-hashed-userpassword-values-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 21:22:39 -0000 This is a cryptographically signed message in MIME format. --------------ms000107040603060309030103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kurt, thanks for your feedback. Kurt Zeilenga wrote: > In writing an I-D for publication as an RFC, there a few options: > 1) Standard Track > 2) Informational > 3) Experimental >=20 > The second two allow for independent submission (directly to the RFC > Editor, don't require IETF consensus, but do require IESG no-objection > (aimed at detecting trying to run a "standard" around the IETF)). I'm not trying to run a standard around IETF. My aim is just to write dow= n what's current practice. > For this particular specification, given past experiences in the IETF L= DAP > WGs and userPassword, I suspect you'll run into standardization issues.= > Even if the IETF wanted to extend userPassword (which is questionable),= the > IETF doesn't own the specification of userPassword in the Directory. > That's owned by the ISO/ITU X.500 committee. So changes/extensions to > userPassword ought to be taken there, not to the IETF. Even if ISO/ITU X.500 committee and IETF see standardization problems thi= s 'userPassword' hash syntax is widely used. I feel it should be documented= pointing out the deficiencies and standardization issues - but fully and completely documented. > Experimental is for, well experiments. Though 2307 was an experiment, = I > think we can say that experiment should be concluded. One could have t= his > I-D conclude the part about userPassword. And informational would be a= n > appropriate track to do especially since given the above userPassword > standardization issue. Well, draft-howard-rfc2307bis-02.txt also aims to be published as Informational which seems appropriate to me given the wide use of the sch= ema described therein. > Informational is also a very good track on stating what current practic= e > is. In addition to providing a specification of that practice (which > should note differences seen in the wild, especially those impacting > interoperability), it should talk about other issues, such as > interoperability issues with implementations adhering to the standard > specifications (here the standard userPassword specification). I thin= k > security issues are important to discuss here (a bit on that in a secon= d). I thought that there is already some text pointing out possible interop i= ssues and security issues. Please provide more concrete points which are missin= g in your opinion. > I see this document is marked as being intended to be published as > Informational, but it reads more like it's trying to be a standard. Well, you don't want me to write a bad/incomplete document just to discou= rage the use of this syntax - do you? > I think trying to standardize this will not go far, so I suggest you ta= ke > a 'document current practice' approach here That 'document current practice' was exactly my plan but still being prec= ise in what is described. > (make it clear in the abstract > and intro that's what the purpose of the document is, and then fulfill = that > purpose throughout the document). The abstract already contains "Furthermore it points out some of the deficiencies of that approach.". I cannot imagine how to be more clear in= the abstract. You're welcome to provide better wording. > Gold star if you conclude the 2307 experiment, at least in the userPass= word > area. Not sure what you mean with "conclude" here. Like it or not I'd estimate that over 95% of LDAP bind requests sent to L= DAP servers are simple bind requests against hashed passwords (IMHO I'm underestimating here). But until now the hash syntax was not fully specif= ied anywhere. This draft is just documentation of what's widely used. IMO there are enough hints to AuthPassword and SCRAM RFCs to point the re= ader into the right direction and there's no wording in this draft which hinde= rs people implementing SCRAM. > Security Considerations: I think that it should be made clear that all= of > these schemes in the doc are quite prone to dictionary and brute force > attack. The viability of these attacks is not generally impacted by th= e > length of the hash but by rate in which the attacker produce a value fr= om > an input. (Salted variants hinders pre-computed dictionary attacks.) The Security Considerations already includes: Applications SHOULD NOT use the non-salted password hash schemes and SHOULD use a sufficiently long salt value. [..] As flaws may be discovered in the hashing algorithm or with a particular implementation of the algorithm or values could be subject to various attacks if exposed, values in attribute 'userPassword' SHOULD be protected as if they were clear text passwords. Especially it is RECOMMENDED to avoid using hashing schemes based on MD-5 because of known weaknesses of this digest algorithm [RFC6151]. (taken from RFC 3112 like mentioned in "Acknowledgements") I've changed/extended it to: Hashed values in attribute 'userPassword' SHOULD be protected as if they were clear text passwords because they are subject to dictionary or other attacks and flaws may be discovered in the hashing algorithm or with a particular implementation of the algorithm. Especially it is RECOMMENDED to avoid using hashing schemes based on MD-5 because of known weaknesses of this digest algorithm [RFC6151]. Applications SHOULD NOT use the non-salted password hash schemes and SHOULD use a sufficiently long salt value. How to make things more clear? > I note that at Isode we have a 2307 style hash scheme that we use to ho= ld > SCRAM compatible hash. Aside from being SCRAM compatible, it's designe= d to > hinder dictionary and brute force attacks by significant increasing the= > cost of producing the stored value. It would be good to include this = as > part of the 'current practice'. You're welcome to provide more information about that to be added. Ciao, Michael. --------------ms000107040603060309030103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTI5MjEyMjI1WjAjBgkq hkiG9w0BCQQxFgQU61DE+XUjB3nGk0f+ZIWLxX8zUzQwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAtsCQEFVf9MxCL+vVs8GbxtU1HlIsy+dB6n59NeHsvL6+zE5skvWNkpqkxG1EVmiRVDPm NOv5RXivAK3SQaF81ylBgC+h0NW8vAIhtYEn0UE+4DexliuYg2LST4iRSI14g5nZVuoDqBq2 fcqA6peXqtTjkMUs1Ai1OA/dQm57FQBHTcJOxa1FZu77baLuKVQP4dYU3a2eEMO0/dfwRxCE Jrrk+FQogtXNO54hiCpkl2aS/0XWC0lKU+MRPAA+avldn5B4yHdcpNYeIQBi9UEY7OmI2yi/ hlnu3E79CcdtmlrgqPCgCZ8UTOFoiFOJTqLc84dMV1k6FvoqsKPzP1LkMAAAAAAAAA== --------------ms000107040603060309030103-- From kurt.zeilenga@isode.com Tue Jan 29 14:23:12 2013 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 ABC4421F8816 for ; Tue, 29 Jan 2013 14:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1fyw2kV-ehL for ; Tue, 29 Jan 2013 14:23:12 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0A39721F8815 for ; Tue, 29 Jan 2013 14:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1359498190; d=isode.com; s=selector; i=@isode.com; bh=eBWYIX6y4/l7CD+sGYBVltlUnAlHVexcXR2dUz15ujM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=M8DKPHahDUcQ75eYBdNpjB4biHeJa6Cn2zGCP9SPJ9jsniY8mYOvg5KdHtUBPGpsfxT81o wA1TYyXTy7jngIzGJJk/fZm1YDncq86qDBKUB7nI0cwEd9XSPmzE67gGlWXRXkZeNXkx9g jXA6dozQrEINl0gaQ78ggja0RpEo9lA=; Received: from pagan.boolean.net (66-214-104-34.dhcp.slto.ca.charter.com [66.214.104.34]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 29 Jan 2013 22:23:10 +0000 From: Kurt Zeilenga In-Reply-To: <51083D91.30205@stroeder.com> Date: Tue, 29 Jan 2013 14:23:05 -0800 Message-Id: <9D086FDB-A4A8-4B6C-BB83-95D901D436E9@isode.com> References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51083D91.30205@stroeder.com> To: =?iso-8859-1?Q?Michael_Str=F6der?= X-Mailer: Apple Mail (2.1499) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ldapext Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 22:23:12 -0000 My comments were not intended to discourage to try to produce a RFC in = this area, but to provide some insight on issues you will face getting = anything in this area published as an RFC. I think an RFC that discussed how standard and various current practices = (note, not singuaral) differ, how the range of current practices differ, = and all of this impacts these differences upon interoperability and = security and other areas of concern, would be useful. A document is simply a technical specification of some additional hash = schemes to an experimental extension is likely not to go down well in = the IETF or the X.500 standards committee, especially if proposed to be = published as anything but experimental independent-submission RFC. Again, this is not intended to discourage you from trying... but more to = let you know what you are getting yourself into. -- Kurt =20= From michael@stroeder.com Tue Jan 29 14:59:46 2013 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 AF79621F87C4 for ; Tue, 29 Jan 2013 14:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE8-R7eQZpOr for ; Tue, 29 Jan 2013 14:59:46 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id D5B9621F87D5 for ; Tue, 29 Jan 2013 14:59:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 8D75860271; Tue, 29 Jan 2013 23:59:44 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBTQ_NvBKa4N; Tue, 29 Jan 2013 23:59:41 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id CE15B6018A; Tue, 29 Jan 2013 22:59:40 +0000 (UTC) Message-ID: <5108545B.5020402@stroeder.com> Date: Tue, 29 Jan 2013 23:59:39 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <5103F924.2070800@stroeder.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51083D91.30205@stroeder.com> <9D086FDB-A4A8-4B6C-BB83-95D901D436E9@isode.com> In-Reply-To: <9D086FDB-A4A8-4B6C-BB83-95D901D436E9@isode.com> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070305000705090805040202" Cc: ldapext Subject: Re: [ldapext] draft-stroeder-hashed-userpassword-values-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 22:59:46 -0000 This is a cryptographically signed message in MIME format. --------------ms070305000705090805040202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: > My comments were not intended to discourage to try to produce a RFC in = this > area, but to provide some insight on issues you will face getting anyth= ing > in this area published as an RFC. Noted. Thanks. > I think an RFC that discussed how standard and various current practice= s > (note, not singuaral) differ, how the range of current practices differ= , > and all of this impacts these differences upon interoperability and > security and other areas of concern, would be useful. Hmm, this is beyond the scope of draft-stroeder-hashed-userpassword-value= s. I think such a comparsion should not include the detailed specifications = for particular mechanisms. IMHO my document could be simply one of the docume= nts such a comparsion could refer to. Ciao, Michael. --------------ms070305000705090805040202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTI5MjI1OTM5WjAjBgkq hkiG9w0BCQQxFgQUn1RVo86glbNEOV/D7O8PzKYGBuswbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAWPPfjv4xq6BgbXEhudbfYCWEJMCRxADo1qaEujAznSAK+CZMiA6wzy3d9d4PNo8afsWV nSElpwijvhdL0wvKR6fhGg4xTFKDDRqJMzY9zREY7xyMzjHiiP/GDNkEhk3nCI6pjDwWn/MH bk8iZ4xvkyZlzE5yREPyVloQ/n5yaZgxFjy5yKbUz1/JdkNz7rJP7BLOHB2nHo1GAvUPUtnH eurbGCSu0vROyvFmdXtac1mpVN1ejqa53QrgMS+vY559S+dWOVzN+2OGvIVTr8djbuFXXvl/ RqTqJekL+aBhWlSZ74EegMe156NQFpgsP9GhoyGPx6KGMcl8tSnHUs+fbgAAAAAAAA== --------------ms070305000705090805040202--