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

[John Larmouth <j.larmouth@salford.ac.uk>]

OK.  I misunderstood you.  I now understand.

John L

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.
> 
> 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>

-- 
   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