Re: [xcbf] X9.84 question - Representation of dates/times

[Alessandro Triglia <sandro@oss.com>]

At 2002/04/15 19:30 -0400, Phil Griffin wrote:


>Alessandro Triglia wrote:
> >
> > At 2002/04/13 08:50 -0400, Phil Griffin wrote:
> >
> > >John Larmouth wrote:
> > > >
> > > > Phil,
> > > >
> > > > Hoyt's posisition is quite tenable.  Cannonical encodings are not
> > > > necessary.  If a signature does not validate against the recieved bit
> > > > pattern, then there is a possibility it has been tampered with, and the
> > > > message should not be trusted.
> > >
> > >Sure.
> > >
> > > > Perhaps you could explain why *you* think canonical encodings are
> > > > useful?
> > >
> > >Canonical encodings remove options for the sender, which
> > >can lead to programs that are more simple to design, and
> > >easier to understand by people who write, test, document
> > >and maintain. That's the key benefit in my opinion.
> >
> > In X9.84, the data block on which the signature was computed is not always
> > a physical portion of the message that is transmitted, and when it is a
> > physical portion of the message it may still be difficult to extract it
> > from the message.
>
>It is certainly true that when confidentiality services
>are provided, the object that is supposed to remain
>confidential is not included in the message. Why does
>this seem to be a surprise to you? This about it. If
>the confidential information is included in the message
>in the clear, it can not be confidential.


Phil, you completely misunderstood me.

I am saying that, in X9.84, the receiver **has to re-encode** the value on 
which the signature was computed - in order to check the signature - for 
one or more of the following reasons:

         1) When privacy is used:  the message doesn't carry in the clear 
the "BiometricData" value that is a part of the value on which the 
signature is computed

         2) With any encoding rules, and in particular with PER, it may be 
difficult to extract a fragment of the encoded message from the entire 
message, without actually decoding the message.

         3) The encoding rules used to encode the value on which the 
signature is computed may not be the same encoding rules used to encode the 
whole message for transmission.


As to point 2, notice that in PER, no "BIT WALKER" can find the first bit 
of an encoded value that is a part of an enclosing value, and then the last 
bit of it, without using the ASN.1 type definitions.  The "bit walker" must 
be a PER decoder.  It may throw away the abstract values it has no interest 
in saving, but it is still a PER decoder.  It may use hand-coded program 
code that embodies the knowledge of how to parse those specific ASN.1 type 
definitions, but it is still a PER decoder, although a specialized one.

Also in XER, a "BYTE WALKER" that is to find the beginning and the end of 
some encoding within an enclosing encoding has to be a XER decoder / XML 
parser. Again, it doesn't need to save the values it finds, but still has 
to know how to parse a piece of XML that is an XER encoding of something.

As to point 3, that can occur when a "BiometricSyntax" message containing 
integrity information was initially encoded in XER but is later re-encoded 
in PER to be relayed over a slow link.  In this case, the whole message is 
re-encoded in PER, but the signature cannot be re-computed for obvious reasons.


For one or more of these reasons (that is, either for the sake of 
robustness, simplicity, interoperability, or just out of necessity), it is 
very advisable that:

         1) The ASN.1 encoding rules used to encode the value on which the 
signature is computed be **canonical**  (C-PER, DER or CXER).

         2) No deviations from the standard specification of the canonical 
encoding rules (X.690, X.691, X.693) be tolerated.

Alessandro