Further Updated current Section 8

Thinking about this, we really need a trojan horse warning.  This can be
added to current 8.4 as follows:

<H3>8.4 <A name=sec-Algorithms>Algorithms</A>, Key Lengths, <u>Certificates</u>, Etc. \
</H3>
<P>Verifying applications must take care not to execute untrusted code
that implements a standard or user specified algorithm such as a <TT>Transform</TT>,
<TT>CanonicalizationMethod</TT>, <TT>DigestMethod</TT>, or <TT>SignatureMethod</TT>.
Depending on the application architecture, executing untrusted code in
these or other cases, such as code implementing a URI scheme from which
source data is being retrieved, could compromise the signature verification
process or the entire application.</P>
<P>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 [<A
href="http://www.w3.org/Signature/Drafts/WD-xmldsig-core-20000114/Overview.html#ref-R\
ANDOM">RANDOM</A>]
and the size of the key, the security of key and certificate authentication and
distribution mechanisms, certificate chain valiation policy,
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. </P>

Donald

------- Forwarded Message

Resent-Message-Id:  <200001252129.QAA25370@www19.w3.org>
Message-Id:  <200001252129.QAA17870@torque.pothole.com>
To:  w3c-ietf-xmldsig@w3.org
Date:  Tue, 25 Jan 2000 16:29:26 -0500
From:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Subject:  Updated current Section 8


This is mostly to bring section 8 up to current WG consensus, fix a
few minor problems, and tone down the sledge hammer pounding about the
obvious fact that unsigned data isn't secure.  This document is going
to be actually used by systems designers and I just don't see the
point of italics and exclamation points when there are plenty of other
ways to be insecure.  Material added is underlined and material
deleted is in double square brackets [[]].

Donald
=====================================================================
 Donald E. Eastlake 3rd                      dee3@torque.pothole.com
 65 Shindegan Hill Road, RR#1                        +1 914-276-2668
 Carmel, NY 10512 USA                             
=====================================================================
<H2>8.0 <A name=sec-Security>Security Considerations</A></H2>
<P>The XML Signature specification provides a very flexible digital signature 
mechanism. Implementors must give consideration to [[the]] <u>their</u>
application threat models 
and to the following factors. </P>
<H3>8.1 <A name=sec-Secure>Only What is Signed is Secure</A> </H3>
<P>A requirement of this specification is to permit signatures to "apply 
to&nbsp;a part or totality of a XML document." [<A 
name=XML-Signature-RD></A>3.1.3 <A 
href="http://www.w3.org/Signature/Drafts/WD-xmldsig-core-20000114/Overview.html#ref-XML-Signature-RD">XML-Signature-RD</A>] 
The <CODE>Transforms</CODE> mechanism meets this requirement by permitting one 
to sign [[a document]] <u>data</u> derived from processing
the identified source [[document]]. For 
instance, applications that wish to sign a form, but permit users to enter<u>limited</u> field 
data without invalidating the form itself might use XPath [<A 
href="http://www.w3.org/Signature/Drafts/WD-xmldsig-core-20000114/Overview.html#ref-XPath">XPath</A>] 
to [[select only]] <u>exclude</u> those portions the user [[does not]]
<u>needs to</u> change. However, 
<CODE>Transforms</CODE> may be arbitrarily specified and may include 
canonicalization instructions or even XSLT transformations. [[<EM>We stress that 
the signature is placed over the derived document, and those portions that were 
excluded by transformation can be arbitrarily modified and the signature will 
still validate! </EM>This is a feature, though one that is used at the 
application's risk. (Some applications may not be willing to trust such 
signatures all-together.)]] <u>Of course, signatures over such a dervied
document do not secure any information discarded by the <CODE>Transforms</CODE>
used.</u> </P>
<P>Furthermore, <A class=link-def 
href="http://www.w3.org/Signature/Drafts/WD-xmldsig-core-20000114/Overview.html#def-ValidationCore">core 
validation</A> behavior does not confirm that the signed [[resource]]
<u>data</u> was obtained 
by applying transforms to the specified source [[document]]. [[This behavior is left 
to the application as core validation only checks the digest values of the 
source document and the signature over <CODE>SignedInfo</CODE>. If this fact is 
important, then additional information (such as by including References to both 
the original and transformed documents) is needed.]] <u>For example, for some
application purposes, it may be adequate to verify an XML signature over a cached
copy of derived data. Other application purposes require vertification that a source
document is still where the signer indicated it was or that a source
document verifies after the specified <CODE>Transforms</CODE>.
In such cases the application
will, in addition to core validation, need to test that the source document can
be retrieved  from the place or validate after <CODE>Transforms</CODE> applied as
indicated in its <CODE>Reference</CODE>.</u> </P>
<H3>8.2 <A name=sec-Seen>Only What is "Seen" Should be Signed</A> </H3>
<P>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 practical 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. </P>
<H3>8.3 <A name=sec-Check>Check the Security Model</A> </H3>
<P>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. 
</P>
<P>With public key signatures, any number of parties can hold the public key and 
verify signatures while only the parties with the [[secret]] <u>private</u> key can create 
signatures. The number of holders of the [[secret]] <u>private</u>
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]] <u>private</u> key is an important issue,
usually addressed by certificate or online 
authority systems. </P>
<P>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. </P>
<P>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 <u>authorized</u>
user [[and thus]] <u>which</u> can 
not be changed the way public or secret keys can be and may have other security 
model differences. </P>
<H3>8.4 <A name=sec-KeyLength>Key Lengths</A>, Algorithms, <u>Certificates</u>, Etc. </H3>
<P>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 [<A 
href="http://www.w3.org/Signature/Drafts/WD-xmldsig-core-20000114/Overview.html#ref-RANDOM">RANDOM</A>] 
and the size of the key, the security of key and certificate authentication and 
distribution mechanisms, <u>certificate chain valiation policy,</u>
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. </P>


------- End of Forwarded Message

Received on Friday, 28 January 2000 07:46:33 UTC