Subject: Re: [Ietf-krb-wg] OTP - KerberosFlags

From: Tom Yu <[email-masked]>
Date: Tue, 28 Jul 2009 08:27:13 -0400

"Srinivas Cheruku" <[email-masked]> writes:

> Hi,
>
>  
>
> OTP draft uses KerberosFlags as follows:
>
>  
>
>              OTPFlags ::= KerberosFlags
>
>              -- nextOTP (0)
>
>              -- combine (1)
>
>  
>
> In RFC 1510/4120, bit 0 is reserved and not used. Is there any good reason
> for not using bit 0?
>
> e.g
>
>    TicketFlags     ::= KerberosFlags
>
>            -- reserved(0),
>
>            -- forwardable(1),
>
>            -- forwarded(2),
>
> ...
>
>  
>
> KDCOptions      ::= KerberosFlags
>
>         -- reserved(0),
>
>         -- forwardable(1),
>
> ...
>
>  
>
> APOptions       ::= KerberosFlags
>
>         -- reserved(0),
>
>         -- use-session-key(1),

This may be due to the form that the DER encoding takes.  When
decoding a 32-bit DER bit string, a natural C language representation
is to put the first bit of the bit string in the MSB of an int, and
the last bit in the LSB, etc.  I suspect that skipping bit 0 was an
effort to avoid integer sign-related bugs in this representation.

If implementations exist that already use bit 0 of OTPFlags, it would
be OK to leave the flag definitions unchanged.  If not, I would
slightly prefer consistency with RFC 4120 by reserving bit 0.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Tue, 28 Jul 2009 11:35:30 -0400

As far as I know there are no implementations of this ID complete yet
and so since there does seem to be a reason to not use bit 0, I'll make
the change in the next update. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Yu
> Sent: 28 July 2009 13:27
> To: Srinivas Cheruku
> Cc: [email-masked]
> Subject: Re: [Ietf-krb-wg] OTP - KerberosFlags
> 
> > In RFC 1510/4120, bit 0 is reserved and not used. Is there any good 
> > reason for not using bit 0?
> >
> > e.g
> >
> This may be due to the form that the DER encoding takes.  
> When decoding a 32-bit DER bit string, a natural C language 
> representation is to put the first bit of the bit string in 
> the MSB of an int, and the last bit in the LSB, etc.  I 
> suspect that skipping bit 0 was an effort to avoid integer 
> sign-related bugs in this representation.
> 
> If implementations exist that already use bit 0 of OTPFlags, 
> it would be OK to leave the flag definitions unchanged.  If 
> not, I would slightly prefer consistency with RFC 4120 by 
> reserving bit 0.