Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue?

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 27 Mar 2003 17:50:14 -0700

Thanks Steven, Ludo or I will fix the ASN.1, and likely produce a
normative appendix containing the full ASN.1, wherein we'll declare
IMPLICIT TAGS.

Jim

>>> "Steven Legg" <[email-masked]> 3/27/03 5:34:57 PM >>>

Mark,

Mark C Smith wrote:
> Someone asked me this week what the correct BER encoding is for a
> PasswordPolicyResponseValue (from
>
http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt

).
>
> The ASN.1 from section 5.2 of the I-D is:
>
>     PasswordPolicyResponseValue ::= SEQUENCE {
>        warning   [0] CHOICE OPTIONAL {
>            timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>            graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>        error     [1] ENUMERATED OPTIONAL {
>            passwordExpired       (0),
>            accountLocked         (1),
>            changeAfterReset      (2),
>            passwordModNotAllowed (3),
>            mustSupplyOldPassword (4),
>            invalidPasswordSyntax (5),
>            passwordTooShort      (6),
>            passwordTooYoung      (7),
>            passwordInHistory     (8) } }

First up, there are syntax errors in this type definition.
It should read:

    PasswordPolicyResponseValue ::= SEQUENCE {
       warning   [0] CHOICE {
           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) } OPTIONAL,
       error     [1] ENUMERATED {
           passwordExpired       (0),
           accountLocked         (1),
           changeAfterReset      (2),
           passwordModNotAllowed (3),
           mustSupplyOldPassword (4),
           invalidPasswordSyntax (5),
           passwordTooShort      (6),
           passwordTooYoung      (7),
           passwordInHistory     (8) } OPTIONAL }

> Notice that the warning element is both OPTIONAL (with a context
> specific tag of 0) and a CHOICE with embedded context specific tags
(0
> timeBeforeExpiration and 1 for graceLoginsRemaining).
> Normally, a CHOICE
> is encoded simply as whatever element as chosen, e.g., if
> timeBeforeExpiration is chosen one would just encode an INTEGER with
a
> context specific primitive tag of 0. But the tag associated with the
> outer element (warning) also needs to be included so the decoder can
> tell that a warning element was included (remember, it is optional).
> What is the right way to encode this?

If the tag default is IMPLICIT TAGS then the encoding is as
you've stated above. The implicit tagging suppresses the universal tag
of the INTEGER, but there is no universal tag (or length) for CHOICE
and implicit tagging never applies to a CHOICE.

With IMPLICIT tags the warning element, when present, is encoded as

    [constructed 0] length [primitive 0] length integer-value-octets

With EXPLICIT tags the warning element, when present, is encoded as

    [constructed 0] length [constructed 0] length
        [primitive UNIVERSAL 2] length integer-value-octets

> One ASN.1 compiler I used encoded the warning element as a
constructed
> element that contains one integer (which allows two tags to
> be encoded,
> one associated with the constructed/container element and one with
the
> integer itself). Is that the right thing to do?

Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't say
whether EXPLICIT or IMPLICIT tagging should apply.

Regards,
Steven

> Can any of the ASN.1
> experts out there help?
>
> Thanks.
>
> -Mark Smith
>   Netscape
>
>
> _______________________________________________
> Ldapext mailing list
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/ldapext 
>

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 30 Mar 2003 22:11:20 -0700

I agree, but I also note that there's not even a requirement for control
values to be described using ASN.1.

>>> "Ramsay, Ron" <[email-masked]> 3/30/03 9:14:04 PM >>>
I think all ASN.1 for a control should be in the form of an ASN.1
module instead of just snippets of ASN.1. RFC 2251 does just this in an
appendix.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Saturday, 29 March 2003 17:48
To: [email-masked] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?

I'd love to do this, but the fact is, values of controls and extended
operations are OCTET STRING types. It's entirely up to the control or
extended operation specification to define the format of the octets
(4.1.11 and 4.12). I believe it would be inappropriate to say anything
other than "if the control (or extended operation) specification
defines
the format of the control value using ASN.1, it SHOULD also specify
that
encoding be in accordance with the rules in 5.1". Even that, I feel is
stretching things a bit. Otherwise the protocol begins to take on
aspects of an extension guide.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 3/28/03 7:39:30 PM >>>
At 06:23 PM 3/28/2003, Jim Sermersheim wrote:
>I bet you're right.  (Now where is that LDAP extensions guidelines
>document...?)

I can add something to draft-zeilenga-ldap-ext about this...
but maybe it *might* be appropriate to cover this in the
revision of Section 5.1 of RFC 2251.  Loosely speaking,
values of controls and extended operations are elements
of LDAP and hence subject to Section 5.1 requirements.

I suggest someone suggest some text to LDAPBIS.

Alternatively (or maybe, additionally), this can be covered
in draft-zeilenga-ldap-ext.  I'd welcome text suggestions.

Kurt

>>>> Mark C Smith <[email-masked]> 3/28/03 7:32:16 AM >>>
>Thank you for your helpful response.
>
>One follow up question: in the absence of any indication, the default
>in 
>ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension 
>documents intend to use IMPLICIT (which for example is specified in 
>Appendix A of RFC 2251) but that fact may not be mentioned. One
>example:
>
>http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt

>-Mark
>Steven Legg wrote:

>OPTIONAL,

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 31 Mar 2003 14:14:04 +1000

I think all ASN.1 for a control should be in the form of an ASN.1 module instead of just snippets of ASN.1. RFC 2251 does just this in an appendix.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Saturday, 29 March 2003 17:48
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?

I'd love to do this, but the fact is, values of controls and extended
operations are OCTET STRING types. It's entirely up to the control or
extended operation specification to define the format of the octets
(4.1.11 and 4.12). I believe it would be inappropriate to say anything
other than "if the control (or extended operation) specification defines
the format of the control value using ASN.1, it SHOULD also specify that
encoding be in accordance with the rules in 5.1". Even that, I feel is
stretching things a bit. Otherwise the protocol begins to take on
aspects of an extension guide.

Jim

Kurt