[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xcbf] X9.84 question - Representation of dates/times
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC