Subject: [ldapext] BER encoding of PasswordPolicyResponseValue?

From: [email-masked] (Mark C Smith)
Date: Thu, 27 Mar 2003 16:52:06 -0500

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) } }

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?

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? 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

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 28 Mar 2003 11:34:57 +1100

Mark,

> PasswordPolicyResponseValue (from
http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt
).
>            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 }

> 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

> 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

---

From: [email-masked] (Mark C Smith)
Date: Fri, 28 Mar 2003 09:32:16 -0500

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

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 31 Mar 2003 15:20:38 +1000

Mark,

Mark C Smith wrote:
> ASN.1 is EXPLICIT tagging, right?

The default for a module definition with an empty TagDefault is
EXPLICIT tagging, but for a fragment of ASN.1 that is not wrapped
in a module definition no particular kind of tagging can be assumed.
The ASN.1 standards don't recognize a standalone type definition
as valid use of the notation.

The tagging issue needs to be addressed by either providing a
module definition, perhaps as a normative annex, or by an explicit
statement in the specification.

In theory we should also be saying something about the extensibility
of any standalone ASN.1 type definition, but this only becomes a critical
concern if PER is being used. X.500 has long had a presumption of
extensibility.

Regards,
Steven 

> I suspect many LDAP extension 
> OPTIONAL,