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

[Phil Griffin <phil.griffin@asn-1.com>]

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.

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>