Suggested Security Considerations Section

I suggest the following as an improved but by no means final Security
Considerations section of the Signature Syntax and Processing document.




Security Considerations

The XML digital signature standard provides a very flexible mechanism.  In
designing a system to make use of it, due consideration should be given to the
threat model being defended against and to the factors covered in the
subsections below.

Only What is Signed is Secure

The flexible Transformations mechanism, including canonicalization and explicit
filtering and extraction, permit securing only a subset of data in an object.
This is good for many applications where a limited portion of an object must
change after the signature or different signatures secure different parts or the
application modifies aspects of the object that are not significant and can be
omitted from signature coverage or the like.   Keep in mind that whenever this
is done, those aspects that are not signed can be arbitrarily modified and the
signature will still validate.

Only What is "Seen" Should be Signed

If signing is intended to convey the judgment or consent of an automated
mechanism or person concerning some information, then it is normally necessary
to secure as exactly as possible the information that was presented to that
mechanism or person.  Note that this can be accomplished by literally signing
what was presented, for example the screen images shown a user.  However, this
may result in data which it is difficult for subsequent software to manipulate.
It can be effective instead to secure the full data along with whatever filters,
style sheets, or the like were used to control the part of the information that
was presented.

Check the Security Model

This standard specifies public key signatures and secret key keyed hash
authentication codes.  These have substantially different security models.
Furthermore, it permits user specified additions which may have other models.

With public key signatures, any number of parties can hold the public key and
verify signatures while only the parties with the secret key can create
signatures.  The number of holders of the secret key should be minimized and
preferably be one.  Confidence by verifiers in the public key they are using and
its binding to the entity or capabilities represented by the corresponding
secret key is an important issue, usually addressed by certificate or on line
authority systems.

Keyed hash authentication codes, based on secret keys, are typically much more
efficient in terms of the computational effort required but have the
characteristic that all verifiers need to have possession of the same key as the
signer.  Thus any verifier can forge signatures.

This standard permits user provided signature algorithms and keying information
designators.  Such user provided algorithms may have further different security
models.  For example, methods involving biometrics usually depend on a "key"
which is a physical characteristic of the user and thus can not be changed the
way public or secret keys can be and may have other security model differences.

Algorithms, Key Lengths, Etc.

The strength of a particular signature depends on all links in the security
chain.  This includes the signature and digest algorithms used, the strength of
the key generation [RFC 1750] and the size of the key, the security of key and
certificate authentication and distribution mechanisms, protection of all
cryptographic processing from hostile observation and tampering, etc.  The
security of an overall system would also depend on the security and integrity of
its operating procedures, its personnel, and on the administrative enforcement
of those procedures.  The factors listed in this paragraph, while critical to
the overall security of a system, are mostly beyond the scope of this document.




Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668

Received on Tuesday, 12 October 1999 23:55:41 UTC