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

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

Yuck!  This seems like a real can of worms.  Can't we simplify this for
the XCBF work in OASIS?  "Simplicity is the essence of security" - quote
from Phil!

John L


Alessandro Triglia wrote:
> 
> At 2002/04/13 13:22 +0100, 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.
> 
> 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:
> 
> BiometricObject ::= SEQUENCE {
>          biometricHeader         BiometricHeader,
>          biometricData           BiometricData
> }
> 
> However "EncodedBiometricObject" is not included in the transmitted message
> *as such* (this type never occurs in X9.84 messages).
> 
> The message is:
> 
> BiometricSyntax ::= CHOICE {
>          biometricObject         BiometricObject,
>          integrityObject         IntegrityObject,
>          privacyObject           PrivacyObject,
>          privacyAndIntegrityObject  PrivacyAndIntegrityObject
> }
> 
> where:
> 
> 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
> }
> 
> 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 (at least in PER).
> 
> 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
> 
> >Perhaps you could explain why *you* think canonical encodings are
> >useful?
> >
> >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
> >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.
> >
> >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>

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