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

[Alessandro Triglia <sandro@oss.com>]

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.

The signature is computed on an encoding of:

EncodedBiometricObject ::= BIOMETRIC.&Type( BiometricObject )


where:

BiometricSyntax ::= CHOICE {
         biometricObject         BiometricObject,
         integrityObject         IntegrityObject,
         privacyObject           PrivacyObject,
         privacyAndIntegrityObject  PrivacyAndIntegrityObject
}

BiometricObject ::= SEQUENCE {
         biometricHeader         BiometricHeader,
         biometricData           BiometricData
}

IntegrityObject ::= SEQUENCE {
         biometricObject         BiometricObject,
         integrityBlock          IntegrityBlock
}

PrivacyObject ::= SEQUENCE {
         biometricHeader         BiometricHeader,
         privacyBlock            PrivacyBlock
}

PrivacyAndIntegrityObject ::= SEQUENCE {
         biometricHeader         BiometricHeader,
         privacyBlock            PrivacyBlock,
         integrityBlock          IntegrityBlock
}


However "EncodedBiometricObject" is not included in the transmitted message 
*as such* (this type never occurs in X9.84 messages).

Even "BiometricObject" is not always present in the message as such.  For 
example, if privacy is used along with integrity, the "biometricHeader" is 
sent as a component of "PrivacyAndIntegrityObject" and the "biometricData" 
is known by the receiver *only after decryption*.

Even when a "BiometricObject" is physically transmitted (as a component of 
IntegrityObject, itself an alternative of BiometricSyntax), in PER it will 
occupy a portion of the whole encoded message from a certain bit position 
to another bit position, difficult to determine without actually decoding 
the message.

Therefore, unless the receiver application has the ability to extract the 
"BiometricObject" from the PER bit stream without decoding the entire 
"BiometricSyntax" message, the only (safe) way it can obtain an 
"EncodedBiometricObject" in many cases is *by re-encoding* the abstract 
data (after decryption, when privacy is used).

Therefore, for X9.84, the encoding rules used to encode the 
"EncodedBiometricObject" for signature computation (that may or may not be 
the same encoding rules used for message transmission) must be *canonical* 
and the encoding must be error-free at both endpoints, otherwise the 
signature check may fail and it won't be possible to tell *why* it failed 
(i.e., whether the encoding was imperfect or the message has been tampered 
with).

Alessandro




>Another benefit comes if there is a relay problem as you
>suggested earlier. Then, when someone along a transmission
>path may have changed the initial encoding, canonical rules
>provide the final recipient with a way to reconstruct the
>initial message.
>
> > If you are saying that something that has been signed by someone is, in
> > practice, always trusted provided the signer is known and trusted,
> > whether the signature validates or not, this makes a complete nonsense
>
>No, that's not what I'm saying at all. What I'm saying
>is that if I trust your signing certificate and your
>signature validates, then I may not mind if the encoding
>of the object that you signed is absolutely incorrect.
>
>There is quite a long history of certificates produced
>or distributed by major browser manufacturers that are
>in some manner malformed. For example, that the wrong
>OID is used for a given extension, or that the encoding
>of an extension object buried in an octet hole uses
>explicit rather than the expected implicit tagging, or
>that SET OF components are not sorted, and on and on.
>
>If you must write an application that relies on such as
>this, and you want to make things work for your customers,
>then you must sometimes hold your nose and be forgiving
>of what you receive from others.
>
> > of a digital signature!  What you are really trusting is that there has
> > been no attack on the underlying network, and that the signature block
> > has not been copied by a hacker from a previous message.  Do people
> > REALLY do this?  I just can't believe it.
>
>No, but they often do not expect that the underlying
>encoding is actually in a correct canonical form. If
>the signature on a hex blob can be verified with a
>trusted key, that is often sufficient.
>
>But there are notable exceptions in financial services
>systems, where every single aspect of a message must
>be valid before trust can be established. Here, no
>incorrect encodings are allowed - you get it right or
>you don't play.
>
>Phil
>
> > John L
> >
> > Phil Griffin wrote:
> > >
> > > John Larmouth wrote:
> > > >
> > > > Phil Griffin wrote:
> > > > >
> > > > > John,
> > > > >
> > > > > John Larmouth wrote:
> > > > > >
> > > > > > This is a difficult discussion.
> > > > > >
> > > > > > A simple starting point is to have a digital signature apply to an
> > > > > > encoding (any encoding).  If the encoding is changed, the 
> signature is
> > > > > > invalid.
> > > > > >
> > > > > > The second stage is to say that the digital signature applies 
> to the
> > > > > > abstract values, and that it should NOT be invalidated by encoding
> > > > > > changes (a false negative problem).  (This is broadly where we 
> are at
> > > > > > today with DER, CXER, CPER, etc.)
> > > > >
> > > > > You mean here I think that there is one and
> > > > > only one way to encode the abstract values,
> > > > > so no encoding options are available, and
> > > > > no changes to the original encoding can
> > > > > occur.
> > > >
> > > > No, I mean that the digital signature is based on a canonical encoding.
> > > > If the signature does not validate the actual bits recieved, then they
> > > > have to be decoded and re-encoded with the canonical encoding rules
> > >
> > > This is really an implementation issue in my opinion.
> > > Am I to risk a denial of service attack, or even just
> > > the overhead of decoding, encoding, then decoding again
> > > each bust message that I receive? I think that how to
> > > handle bust messages is best left to the application.
> > >
> > > > before you can be sure there has been tampering.  (Invalidity of the
> > > > signature.)
> > >
> > > Failure of the signature to validate, by itself, is
> > > insufficient to assert that there has been tampering.
> > > If an incorrect encoding is signed, encoding the same
> > > abstract values correctly should produce an invalid
> > > signature. This is a benefit of never decoding and
> > > attempting to reconstruct the original message, but
> > > instead preserving whatever encoding that was
> > > initially signed and sent.
> > >
> > > > This process avoids the false negatives that might occur due to changes
> > > > in the encoding that do not change the abstract values.
> > > >
> > > > *** This is the only reason we have canonical encoding rules. ***
> > > >
> > > > > Note though John that even this does not save
> > > > > us from poor implementation that leads to
> > > > > invalid encodings.
> > > >
> > > > If someone generates an encoding that is invalid, it can never produce
> > > > abstract values, and should never be accepted against a signature.
> > >
> > > But in practice on the net this is not what happens.
> > > It is often a matter of trusting the signer. Folks
> > > try to get along, and to be careful in what they
> > > send and forgiving in what they receive. For example,
> > > the dER vs DER issue only recently resolved.
> > >
> > > In some protocols, if the receiver trusts the signer
> > > and the signature on a hex blob is valid, then it does
> > > not matter if the encoding of the blob itself is correct.
> > > But in others, everything must be perfect or the signed
> > > object is treated as invalid.
> > >
> > > > > > The third stage - which several e-mails recently have touched 
> on (and
> > > > > > yours has really focussed on) is to say that the signature 
> should be
> > > > > > applied to the semantics transferred, so it should not be 
> invalidated
> > > > > > (false negatives) by a change in the abstract syntax carrying the
> > > > > > semantics (in this case additional or missing relative OID 
> components).
> > > > >
> > > > > The proposal here to eliminate sender trailing zero
> > > > > options has minor benefit. Receivers are still required
> > > > > to assure that all values are reasonable for use. But to
> > > > > either require or to recommend that trailing zeros be
> > > > > omitted is easy to do in an application and it provides
> > > > > direction for implementors.
> > > >
> > > > That is not the point.  The issue is whether a signature is validating
> > > > the semantics or the encoding.  If you want to avoid false negatives
> > >
> > > This can depend on the protocol requirements.
> > >
> > > > against the semantics, you need to define a canonical abstract syntax -
> > > > no trailing zero optional elements in your date relative OID, or all
> > > > optional elements present.
> > > >
> > > > > But it wouldn't hurt to say that senders shall omit these
> > > > > values and receiver shall be prepared to accept them.
> > > >
> > > > This is nothing to do with the discussion.  We are talking about when a
> > > > signature is to be considered valid.
> > >
> > > Not me. I'm talking about application semantics
> > > and whether to bother or not to restrict options.
> > >
> > > > > As I stated in this thread, if the receiver preserves the
> > > > > encoding used in the signature process as sent, it does
> > > > > not even matter if the encoding is not canonical or that
> > > > > it is encoded correctly.
> > > >
> > > > Of course.  That is my stage 1, and what Hoyt advocates.  In this case
> > > > you do not need canonical encoding rules.  Not a position that ASN.1
> > > > advocates would like to take!
> > >
> > > Beyond any encoding rules, the protocol or the
> > > application level can specify behaviors such as
> > > deferred decoding on particular components. This
> > > can sometimes eliminate the need for canonical
> > > encodings.
> > >
> > > Phil
> > >
> > > > John L
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > --
> >    Prof John Larmouth
> >    Larmouth T&PDS Ltd
> >    (Training and Protocol Development Services)
> >    1 Blueberry Road
> >    Bowdon                               j.larmouth@salford.ac.uk
> >    Cheshire WA14 3LS                    Tel: +44 161 928 1605
> >    England                              Fax: +44 161 928 8069
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>