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=== message truncated ===
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.are named bits.
Phil Griffin
John Larmouth wrote:
This one is very tricky.
Trailing zero bits are not significant when there
encoded value. WhatThe size constraint has not been violated by the
value terms is ahas been transferred by the encoding, in abstract
the fist bit set and*set* of values of infinite length, all with only
canonical - on this stuffall other bits set to zero. (DER text -
encoders options. Butgets interesting, if you read it!) All else is
*abstract* valuesthe SIZE constraint does indeed restrict the
and so what is being(independently of the named bits specification),
etc up tosent is !1000000000000000', '1000000000000000',
**all of which carry the'10000000000000000000000000000000000000000',
new version since 1984,same semantics**.
(I hate this stuff - every time we have made a
clean model andwe have tinkered with the text to try to get a
was fundamentallyspecification. Basically, the named bits stuff
I say above fits theflawed way back in 1982. But I believe that what
encoding is valid.)current text - and indeed most earlier text. The
size constraint is onIn specific reply to Ed: the restriction of the
encoded.the abstract values. Not on the way they are
this case must beJohn L
Ed Day wrote:
It is my opinion that the size constraint in
Clearly, the person whorespected; otherwise, it has no meaning.
be between 15 and 32wrote this definition wanted the bit string to
would not have beenbits in length, otherwise the size constraint
stating this, I couldadded. As to precise language in the standards
<mailto:[EMAIL PROTECTED]>not find any.
Regards,
Ed Day Objective Systems, Inc. REAL WORLD ASN.1 AND XML SOLUTIONS Tel: +1 (484) 875-3020 Fax: +1 (484) 875-2913 Toll-free: (877) 307-6855 (USA only) mailto:[EMAIL PROTECTED] http://www.obj-sys.com
----- Original Message ----- From: Wiehe Ulrich
problem resulting fromTo: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Sent: Friday, February 28, 2003 4:27 AM Subject: [ASN.1] Question on BER
Dear ASN.1 experts
In order to solve an interoperability
your help on the followingdifferent interpretations of ITU-T X.690,
type for which thequestion is very much appreciated:
A BER encoded message contains a data
abstract syntax is defined as
DataType ::= BIT STRING {
bitOne (0),
bitTwo (1),
bitThree (2),
bitSeven (6),
bitEight (7),
bitNine (8),
bitFour (3),
bitFive (4),
bitSix (5),
__________________________________________________ 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
