Issue 17 in openssh-lpk: sshPublicKey and ldapPublicKey should be optional

[codesite...@google.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 17 by pa...@buzbox.net: sshPublicKey and ldapPublicKey should be
optional
https://code.google.com/p/openssh-lpk/issues/detail?id=17

Hello,

Could someone please explain why these attributes are set to MANDATORY, is
there something I'm not understanding from a security point of view? Does
the patch behave differently if it cannot find the attributes or something?

Thanks,

Pauly

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[codesite...@google.com]

Comment #1 on issue 17 by pa...@buzbox.net: sshPublicKey and ldapPublicKey

should be optional
https://code.google.com/p/openssh-lpk/issues/detail?id=17

..in the supplied schema btw ;)

[codesite...@google.com]

Comment #2 on issue 17 by danlis...@gmail.com: sshPublicKey and

ldapPublicKey should be optional
https://code.google.com/p/openssh-lpk/issues/detail?id=17

The "MANDATORY" is not a setting, it is a description.

Actual mandatory requirements are identified by the class defined as
SUPerior (ie top, which is always available), and any MUST have
attributes. These schema files state MAY, allowing you to have the
objectclass (enabling future use of the service) without actually turning
it on until the sshPublicKey attribute is assigned/populated. This could
also be arguable, such that it does not make sense to provision the
objectclass without providing its only (currently) useful attribute. In
this case, changing sshPublicKey to MUST would make sense.

In my opinion, the SUP should be moved down the LDAP tree to a more
appropriate level such
as 'person', 'organizationalPerson', 'inetOrgPerson', 'organization', 'organizationalUnit', 'account',
or 'posixAccount'. The ssh service is not available to anyone/anything
that does not have a defined account on any system.
Not every object in every level of of the DIT should be able to have an
_authentication_ objectclass and attribute(s).

I do not believe this to be a bug. The issue however confusing is, it does
not provide value to include the word MANDATORY in the DESCcription.