perl-ldap-dev

Handling of unexpected ASN.1

[Chris R. <chr...@me...>]

(Obscure concern coming up!)

I believe that LDAP clients/servers are meant to be able to ignore
'unexpected' elements in ASN.1 SEQUENCEs (RFC 2251 section 4 para 1). This
is to promote compatibility with future clients/servers which may be using
a version of the protocol with extra stuff in.

I don't think Net::LDAP can handle this. Well, I think this is really
something that Convert::ASN1 cannot handle. eg:

-------------------
my $decode = Convert::ASN1->new();
my $encode = Convert::ASN1->new();
# Attempt to allow for extra stuff when decoding
$decode->prepare(q<
		 SEQUENCE {
		     version INTEGER,
		     name    OCTET STRING,
		     ext     ANY OPTIONAL
		 }
		 >);
$encode->prepare(q<
		 SEQUENCE {
		     version INTEGER,
		     name    OCTET STRING,
		     flag    BOOLEAN,
		     foo     PrintableString
		 }
		 >);

my $pdu = $encode->encode(version => 1,
			  name => 'cn=Chris Ridd',
			  flag => 1,
			  foo => 'foo');

my $o = $decode->decode($pdu);
# Returns undef.
-------------

If there is only one extra parameter in the encoded SEQUENCE, the 'ANY'
catches it, which is correct. More than one extra parameter though, and the
decode rightly fails.

What is needed (I think) is for a mechanism to allow for 'all remaining'
elements of a SEQUENCE to end up in a single variable. In the Convert::BER
days, this was done with a magic 'BER' type. This is OK if all the new
extensions in the SEQUENCE are added at the end of the SEQUENCE - there's
no guarantee that they will be all at the end of course...

Alternatively, there should be a way to configure a Convert::ASN1 object to
ignore unknown things when decoding. (This option shouldn't be the default.)

Does this make any sense?

Cheers,

Chris

Re: Handling of unexpected ASN.1

[Graham B. <gb...@po...>]

On Fri, Mar 23, 2001 at 05:22:33PM -0000, Chris Ridd wrote:
> (Obscure concern coming up!)
> 
> I believe that LDAP clients/servers are meant to be able to ignore
> 'unexpected' elements in ASN.1 SEQUENCEs (RFC 2251 section 4 para 1). This
> is to promote compatibility with future clients/servers which may be using
> a version of the protocol with extra stuff in.
> 

> If there is only one extra parameter in the encoded SEQUENCE, the 'ANY'
> catches it, which is correct. More than one extra parameter though, and the
> decode rightly fails.

I think this should be done as an option to the decoder, rather than modifying
the ASN.1

> What is needed (I think) is for a mechanism to allow for 'all remaining'
> elements of a SEQUENCE to end up in a single variable. In the Convert::BER
> days, this was done with a magic 'BER' type. This is OK if all the new
> extensions in the SEQUENCE are added at the end of the SEQUENCE - there's
> no guarantee that they will be all at the end of course...

Hm, well I cannot see an easy way to support new elements anywhere without
a considerable slowdown.

> Alternatively, there should be a way to configure a Convert::ASN1 object to
> ignore unknown things when decoding. (This option shouldn't be the default.)

Are you saying an option to skip anything unknown and ignore extra at end
of sequences, just as long as everything expected is extracted ?

That sounds simple, but becomes more complex when you have to consider the
situation where a new element is added before an existing element which is
already optional.

Graham.

Re: Handling of unexpected ASN.1

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> On Fri, Mar 23, 2001 at 05:22:33PM -0000, Chris Ridd wrote:
>> (Obscure concern coming up!)
>> 
>> I believe that LDAP clients/servers are meant to be able to ignore
>> 'unexpected' elements in ASN.1 SEQUENCEs (RFC 2251 section 4 para 1).
>> This is to promote compatibility with future clients/servers which may
>> be using a version of the protocol with extra stuff in.
>> 
> 
>> If there is only one extra parameter in the encoded SEQUENCE, the 'ANY'
>> catches it, which is correct. More than one extra parameter though, and
>> the decode rightly fails.
> 
> I think this should be done as an option to the decoder, rather than
> modifying the ASN.1

Yes, I tend to agree.

>> What is needed (I think) is for a mechanism to allow for 'all remaining'
>> elements of a SEQUENCE to end up in a single variable. In the
>> Convert::BER days, this was done with a magic 'BER' type. This is OK if
>> all the new extensions in the SEQUENCE are added at the end of the
>> SEQUENCE - there's no guarantee that they will be all at the end of
>> course...
> 
> Hm, well I cannot see an easy way to support new elements anywhere without
> a considerable slowdown.
> 
>> Alternatively, there should be a way to configure a Convert::ASN1 object
>> to ignore unknown things when decoding. (This option shouldn't be the
>> default.)
> 
> Are you saying an option to skip anything unknown and ignore extra at end
> of sequences, just as long as everything expected is extracted ?

Something like that.

> That sounds simple, but becomes more complex when you have to consider the
> situation where a new element is added before an existing element which is
> already optional.

Hm. If we limited this to just ignoring stuff at the end would it be
simpler?

> Graham.



Cheers,

Chris

Re: Handling of unexpected ASN.1

[Graham B. <gb...@po...>]

On Sat, Mar 24, 2001 at 07:26:23AM -0000, Chris Ridd wrote:
> > Are you saying an option to skip anything unknown and ignore extra at end
> > of sequences, just as long as everything expected is extracted ?
> 
> Something like that.
> 
> > That sounds simple, but becomes more complex when you have to consider the
> > situation where a new element is added before an existing element which is
> > already optional.
> 
> Hm. If we limited this to just ignoring stuff at the end would it be
> simpler?

Yes, I think that would be simpler to implement.

Graham.