Erik Andersen wrote:
Hi Folks, During the recent meeting in Geneva, the Working Document on Password Policy was advanced to PDAM status. The document is now out for vote with SC6. A link to the PDAM text may be found on http://www.x500standard.com/index.php?n=Ig.Extension.
Just from a quick readthru:page 6 uses pwdAdminSubentry[List], page 39 uses pwdPolicySubentry. For consistency's sake I think pwdPolicySubentry is better but these need to be changed to agree with each other.
Also for consistency, I'd suggest uniformly using "pwd" as the prefix on all attributes. This would affect:
minPwdLength pwdMinLength myPwdAttribute pwdAttribute changePwdAllowed pwdChangeAllowd modifyEntryPwdAllowed pwdModifyEntryAllowed recentlyExpiredPwdDuration pwdRecentlyExpiredDuration passwordHistory* pwdHistory*(Note that page 12 sec 11.6 references pwdHistory, not passwordHistory, so there's already confusion over the naming scheme.)
page 13 subclause 12.9 Maybe consider renaming here too: insufficientPasswordQuality pwdInsufficientQuality passwordInHistory pwdInHistory noPasswordSlot pwdHistoryFull but that's really just an afterthought. page 20 Annex A This looks comparable to the labeledURI attribute. http://www.ietf.org/rfc/rfc2079.txt"Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)"
perhaps that can be reused here.On a separate note, outside the scope of this discussion, I wish we had an actual URI syntax. URIs have well defined rules for format/construction; shoving them into a plain directory string is pretty sloppy.
page 22 Annex A"password" is similar to simpleSecurityObject. Perhaps this objectclass name should be more explicit, like userPwdObject. Again, just an afterthought.
page 28 220.127.116.11 gracesUsed -> pwdGracesUsedit also references the "graces" attribute, which is obviously supposed to be "pwdGraces".
page 29 18.104.22.168.1 typo in section title "Lzngth" -> "Length" page 30 22.214.171.124.3 Password Alphabet Attributeis it worthwhile to define a bit for 'nonPrintableCharacters' ? I frequently use passwords with TAB, BEL, SOH, STX, VT, FF, and other control characters included. Maybe that's just me.
page 37 annex LI thought it was agreed that the language should be "hashing algorithms" not "encryption algorithms" ...
L.2/L.3 where is the definition of how many bits of salt should be used? The lack of a spec for this in LDAP has already caused interoperability issues between OpenLDAP and e.g. ApacheDS.
I'll followup later with another review in terms of the current LDAP ppolicy draft.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ----- www.x500standard.com: The central source for information on the X.500 Directory Standard.