On Thu, 18 Sep 2014 14:22:07 -0400
Nathaniel McCallum <npmccal...@redhat.com> wrote:
> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote:
> > On Thu, 18 Sep 2014 13:56:44 -0400
> > Nathaniel McCallum <npmccal...@redhat.com> wrote:
> > > -objectClasses: (2.16.840.1.113722.214.171.124.2.2 NAME
> > > 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type'
> > > MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $
> > > ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) MAY
> > > (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') +objectClasses:
> > > (2.16.840.1.1137126.96.36.199.2.2 NAME 'ipatokenTOTP' SUP ipaToken
> > > STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $
> > > ipatokenOTPalgorithm $ ipatokenOTPdigits $
> > > ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep $
> > > ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP')
> > NACK, you cannot move from MAY to MUST.
> This is precisely what we have been discussing on IRC today. The
> consensus was that this was acceptable because of the update plugin
> and the rarity of the state in which a token would not have
> ipatokenTOTPwatermark set (the token has to be created an never used).
Sorry I was not around, but it is never acceptable, as it may cause
This has been a long (albeit perhaps unspoken) rule in changing schema
Existing objectlasses can *never* gain new MUST attributes. This rule
is rigid and is non-negotiable.
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list