Subject: Cross-purpose SEQUENCE/CHOICE protocol extension fields

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 7 Nov 2004 22:13:45 +0100

There are two different ways to extend BindResponse and ModifyRequest.
I imagine this may lead to some sort of conflict or at least a rather
messy situation, in particular in which order the fields should occur:

1) If one defines a new BindRequest.AuthenticationChoice or
   ModifyRequest.changes.change.operation, one may need a new matching
   sequence element in BindResponse or ModifyRequest.changes.change.

2) One may define trailing SEQUENCE elements; [Protocol] section 4 says
   implementation must ignore unrecognized trailing SEQUENCE elements.

I don't know that works when there are several extra SEQUENCE elements
present:  Will an implementation pick up a known element following an
unknown element?  Can elements from different specifications be present
in any order?  Or must all specifications of such elements define where
in the SEQUENCE the element occurs in relation to all previous
specifications of other elements?

If this is not a problem, ignore the rest of this message.  Otherwise:
One fix might be to define (not in LDAPbis) two extensions to be used
with future specifications of Bind authentication choices and Modify
operation types:

        -- appended to BindResponse
        BindAuthData ::= [something] CHOICE {
             -- currently no choices are defined
        }

        -- appended to ModifyRequest.changes.change
        ModifyChangeData ::= [something] CHOICE {
             -- currently no choices are defined
        }

where each CHOICE tag number is reserved for the same
BindRequest.AuthenticationChoice tag number and
ModifyRequest.changes.change.operation value.

If this is desirable, I don't know if such a draft could - or should -
be rushed out quickly enough that [protocol] and [ldapiana] can add a
(maybe informative) reference to it?

For reference, here are the current ASN.1 definitions:

        BindResponse ::= [APPLICATION 1] SEQUENCE { 
             COMPONENTS OF LDAPResult, 
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

        ModifyRequest ::= [APPLICATION 6] SEQUENCE { 
             object          LDAPDN, 
             changes         SEQUENCE OF change SEQUENCE { 
                  operation       ENUMERATED { 
                       add     (0), 
                       delete  (1), 
                       replace (2) }, 
                  modification    PartialAttribute } }

As far as I can tell there are no other protocol fields with similar
troubles, but I make no promises:-)

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 7 Nov 2004 22:34:27 +0100

>    implementation must ignore unrecognized trailing SEQUENCE elements.

Sorry, that was unclear.
(1) of course employs what (2) says.
With (2) I meant to define such SEQUENCE elements for some different
purpose, independent of the AuthenticationChoice/operation.

-- 
Hallvard

---

From: Steven Legg <[email-masked]>
Date: Tue, 09 Nov 2004 11:48:26 +1100

Hallvard,

>    implementation must ignore unrecognized trailing SEQUENCE elements.

LDAP uses ASN.1 and ASN.1 has rules for extensibility. Extensions to LDAP
should always be consistent with those rules.

> unknown element?

Extensibilty in ASN.1 is essentially linear and assumed to be employed through
standards actions (user-defined extensions are handled through open types
with component relation constraints - directory attributes fall into this
category). If one follows the ASN.1 rules for extensibility then a known
element will never follow an unknown element.

 > Can elements from different specifications be present
> in any order?

No. One of the specifications must logically follow the other and take
account of it.

 > Or must all specifications of such elements define where

Yes, mostly. The "where" is always at the end (unless the base specification
explicitly put extension marks somewhere else).

Regards,
Steven

---

From: Rici Lake <[email-masked]>
Date: Mon, 8 Nov 2004 20:09:05 -0500

On 8-Nov-04, at 7:48 PM, Steven Legg wrote:

> If one follows the ASN.1 rules for extensibility then a known

Surely that is not true. If there is an extension marker in
the base specification, that's where extensions go; there is
no requirement that it be at the end. Furthermore, there might
be an extensible CHOICE in the middle of a SEQUENCE.

X.680 (07/2002), 48.1 (just after a note that extension markers
have no effect on BER); "The extension marker ... makes no statement
as to how such additions should be handled other than that they
should not be treated as an error during the decoding process."

---

From: Steven Legg <[email-masked]>
Date: Tue, 09 Nov 2004 15:28:30 +1100

Hi Rici,

Rici Lake wrote:
> Surely that is not true.

To clarify, I was talking about the immediate components of a SEQUENCE, SET
or CHOICE. Of course, any of the immediate components could itself be an
extensible SEQUENCE, SET or CHOICE. I was also ignoring the double extension
marker notation since the LDAP specification hasn't made use of it.
To be more precise I should say "If one follows the ASN.1 rules for
extensibility then a known extension will never follow an unknown extension
of the same SEQUENCE, SET or CHOICE type".

 > If there is an extension marker in
> no requirement that it be at the end.

True, but it would be unusual to put a single extension marker before
the end in the *base* specification, in effect creating some predefined
extensions. In any case, since it is the *base* specification those
prefined extensions are known. Any subsequent extension has to go after
the previously defined extensions, so it will still be the case that an
unknown extension follows the known extensions of the type with the
extension marker.

 > Furthermore, there might

Yes, but any new extension to the CHOICE will appear at the end of
the CHOICE definition.

> should not be treated as an error during the decoding process."

X.608 (07/2002), G.1 is more instructive. It says 'Table G.1 shows the ASN.1
types that can form the extension root type of an ASN.1 extension series, and
the nature of the single extension addition that is permitted for that type
(multiple extension additions can of course be made in succession, or together
as an extension group).'

Under SEQUENCE and SET, Table G.1 allows 'Addition of a single type or extension
group to the *end* of the "ExtensionAdditionList".' The emphasis is mine.

Under CHOICE, Table G.1 allows 'Addition of a single "NamedType" to the *end* of
the "ExtensionAdditionAlternativesList".'

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Nov 2004 10:02:48 -0500

At 07:48 PM 11/8/2004, Steven Legg wrote:
>Extensibilty in ASN.1 is essentially linear and assumed to be employed through standards actions (user-defined extensions are handled through open types with component relation constraints - directory attributes fall into this category).

It's my view that guidelines for kinds of ASN.1 extensions are
best left to future documents.

Kurt