Re: [ASN.1] Question on BER

[John Larmouth]

Here I will disagree with Olivier.  It is not so much that the rule has 
been changing, but that the way of expressing it in text has been 
changing.  As I said earlier, I do not believe that there is text in 
earlier versions that cannot be interpretted in line with the current 
text.  It is just that earlier text was imprecise or even down-right 
ambiguous.

John L

Edmond G wrote:
Something about this point is also mentioned in the
book "ASN.1 communication between Heterogeneous
Systems by Mr Dubuisson".
BitStringValue(when IdentifierList is used):
...
Designers should then make sure that the presence or
absence of trailing zerors remains meaningless for the
application(no semantics should be assosicated with
this). This rule has been changing depending on the
versions of the ASN.1 standard; it should therefore be
applied with great care.
...
Ed

--- John Larmouth <[EMAIL PROTECTED]> wrote:

This is a really tricky one!  Specifications in
earlier versions of 
ASN.1 were often imprecise in tnis area (I might
even say downright 
ambiguous!).  But I do not think they were actually
erroneous.

It was always (I think) the case that DER required
the omission of all 
trailing zero bits when there was a named bit list,
right from the very 
first version of DER (although maybe not in the very
original X.509 spec).

It was also always the case that anything that was a
DER encoding was a 
valid BER encoding.

So a DER encoding with a transmission of a single
one-bit (with all 
other bits in the octet flagged as unused) would be
a valid BER encoding 
for an abstract value with a SIZE constraint of 16
to 32, or whatever.

I am sure the text *implied* this in all previous
versions of ASN.1. 
Whether it clearly *said* it may more debatable! 
But I will be 
surprised if you can find text in older versions
that clearly 
contradicts the above.

But then I could be wrong!

John L

Edmond G wrote:

The one open point is different handling of this
case

in ASN.1 standards. So if that's an older protocol
using ASN.1 standard 208,209 , the adding and
removing

of zeros (trailing bits) is not allowed. So for
the

decoder (in this case) would means invalid value
and

decoding error when the SizeConstraint is
violated.

Is this right? 

Ed

--- John Larmouth <[EMAIL PROTECTED]>
wrote:

There is absolutely no reason why any tool should
not enforce 
constraints, whatever the encoding that is in use,
and whatever the form 
of a constraint - even a comment, if the tool is
clever enough.

That was not the issue.  The issue was not whether
you could transmit 
abstract values outside the size constraint - you
can't (legally), in 
BER or in PER or in DER or in XER or anyhwere

else.

The issue was 
whether the given encoding was a valid BER

encoding

for a value in the 
range of the size constraint, and it was.

John L

Phillip H. Griffin wrote:


I don't disagree in a purely "technical" sense.
But I do agree


that it is up to the protocol that uses ASN.1,

and

not to ASN.1


alone, as to what is actually a valid message.

The constraint was intentionally placed in the
message definitions.


I would assume that this rule was meant to be
enforced. But where


this rule is enforced is a key issue.

ASN.1 tool vendors and ASN.1 application

providers

may provided


a "strict" switch that causes the constraints to
be enforced so that the


protocol rules are obeyed as written, even if the
ASN.1 standards


do not require the constraints to be enforced in

a

given encoding


rules.

The encoder tool obeying the ASN.1 as written
would then detect the


encoding to be in error. But a 'vanilla' coder
tool might choose to just


obey the ASN.1 standards and leave it to the
underlying application


that uses the coder tool to enforce the rest of
the protocol.


That is the underlying application, not the coder
tool itself, may be


required to enforce the constraint specified in
the protocol. Clearly some


piece of code must enforce the protocol as

written

or the constraint should


never have been written at all.

A tool vendor may allow his tools to "see" the
constraints and enforce


them even in BER. This takes the burden off of

the

underlying application


and places the burden for enforcing the protocol
on the coder tool.


The SET protocol was defined such as this using
ASN.1 and encoded in


DER. A set of guidelines was written for testers
that made it clear what


errors had to be detected by implementers of the
protocol. And in some


cases, the guidelines made it clear that the

coder

tool was required to


enforce some protocol behavior that was outside

of

the scope of the


ASN.1 standards.

This situation sounds like the SET case and would
seem to need some


guidance for implementers as to what is and what
is not a valid protocol


message - not merely what is valid ASN.1.

Phil Griffin

=== message truncated ===

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/



--
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Development Services)
   1 Blueberry Road
   Bowdon                               [EMAIL PROTECTED]
   Cheshire WA14 3LS                    Tel: +44 161 928 1605
   England                              Fax: +44 161 928 8069