- From: merlin <merlin@baltimore.ie>
- Date: Tue, 29 Aug 2000 13:40:22 +0100
- To: "John Boyer" <jboyer@PureEdge.com>
- Cc: "XML DSig" <w3c-ietf-xmldsig@w3.org>
Hi,
I meant to bring this up on the last teleconf but forgot..
1)
" 3. replace any element node E with E plus all descendants of E (text,
comment, PI, element) and all namespace and attribute nodes of E and its
descendant elements. "
" To retain comments while selecting the entire document, use the following
full XPointer: URI='#xpointer(//. | //@* | //namespace::*) "
I'm not sure if there is a subtlety that is lost on me, but would not
'#xpointer(/)' select the whole document? '/' returns the root node
which, by 3, is automatically expanded to include all descendants.
2)
" 1.Initialize an XPath evaluation context by setting the initial
node equal to the input XML document's root node, and set the
context position and size to 1. "
By "initial node" I presume you mean "context node"?
This is troublesome: If I do an XPath on URI='#foo' then the XPath
expresion '.' is not 'id("foo")' but '/'. In other words, XPath
and fragmentary URIs are incompatible. See 5) below.
This is particularly important because, although an XPath can reflect
the position of the node at signing time, if it is moved into another
document then it will not verify.
3)
Namespace attributes, C14N, XPaths and XPointers. I'll write this
shortly.
4)
An XSLT is applied to an XML document, so why a binary input type?
I have no strong opinion on this, it is just an observation.
5)
The current content distinction of "binary" or "node set" does not
seem sufficient to me. I should I have raised this earlier, but...
In my implementation, and I think this might be reflected in others,
I distinguish three content types: "binary", "node set" and "node
tree". A tree being a limited set.
The output of a fragment or empty URI is a tree. The output of an
XPath, XSLT or full XPointer is a set which may be a tree.
The input to an XPath or XSLT is a tree. More importantly, the
context node is the root of the tree. This is why a set is invalid.
But a set which is a tree is okay.
Also, a complexity arises in whether an expression should be
allowed to go above the context node '..' / '/; or not.
My suggestion would be that we should mandate that the context
node should be treated as the document root node during XPath
processing (and it should inherit appopriate attributes). In
other words, our transform should operate indistinguishably were
a C14N/parse step present.
This can be implemented efficiently with a slightly customized
XPath processor, and on a standard XPath processor by simply
performing the explict C14N/parse step.
Things don't seem to be coming together terribly cleanly, whatever
we do.
Merlin
r/jboyer@PureEdge.com/2000.08.22/13:25:24
>This is a multi-part message in MIME format.
>
>------=_NextPart_000_003E_01C00C3C.6DC37130
>Content-Type: multipart/related;
> boundary="----=_NextPart_001_003F_01C00C3C.6DC37130"
>
>
>------=_NextPart_001_003F_01C00C3C.6DC37130
>Content-Type: multipart/alternative;
> boundary="----=_NextPart_002_0040_01C00C3C.6DC37130"
>
>
>------=_NextPart_002_0040_01C00C3C.6DC37130
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>Hello all,
>
>Attached is a copy of the latest editors' copy of the XML DSig
>specification, except that I have added and deleted the text necessary to
>implement the new Reference/Transform processing model discussed in the most
>recent teleconference.
>
>The sections of HTML surrounded by <u></u> and <strike></strike> were added
>by the editors prior to my receiving the document. The sections surrounded
>by <u john="john"></u> and <strike john="john"></strike> reflect the
>modifications I made. There turns out to be quite a large number of
>changes, so I would ask as many of you as possible to really read over the
>new document, esp. the content appearing in underlined red (though that text
>is a mix of my additions and the former additions by the editors).
>
>Despite the large number of changes, I have tried to change the behavior of
>as few things as humanly possible. Below is a manifest of the things I can
>recall changing:
>
>1) Obviously the changes have fixed the enveloped signature transform.
>
>2) Removed requirement for barename XPointer support from external
>resources. We nevery really had this support, we just really haven't
>acknowledged it before. Also, I glommed onto the definition of
>same-document reference from RFC2396 as the way to distinguish when we do
>require barename XPointer support. Same-document reference covers the null
>URI plus URIs that essentially start with a #.
>
>NOTE: We could recover id processing by adding a REQUIRED 'id' transform
>that performs the same function as the xpointer I defined in the text. If
>we do that, then I'd say for the sake of consistency that the other xpointer
>I defined should be done as a transform too, as well as the notion of null
>URI (which excludes comments). The point of these other two is to make sure
>we can convert from octet streams to node-sets with or without comments. As
>well, the three ideas may be expressible as a single Transform with a
>parameter. I'd be happy to take a stab at writing this up if the WG would
>like.
>
>3) Added idea that same-document URIs in the Reference would result in a
>location-set, then defined how to boil the location-set down to an XPath
>node-set (which is pretty easy considering an XPointer location set is a
>node-set except for the addition of point and range ndoes). BTW, the new
>text is careful to say 'XPath node-set (or sufficiently functional
>alternative)' or words to that effect throughout the document.
>
>4) Rewrote text of all Transforms such that they indicate whether they input
>and output an octet stream or a node-set. Rewrote text surrounding
>DigestMethod so that it is clear that if the input is not an octet stream,
>then the node-set gets canonicalized.
>
>5) Rewrote material around how to generate textual input for
>SignatureMethod. Basically, made it clear that SignedInfo is canonicalized
>within the context of the surrounding document, which was not previously
>stated.
>
>6) As a result of the new processing model, it was possible to upgrade the
>behavior of the base 64 transform so that it automatically strips away the
>start and end tags if the base 64 content is within XML. (Being able to do
>this on XML elements derived from external resources would be a great reason
>to have a transform that does 'id' resolution).
>
>7) Changed XPath so that it iterates on all nodes in a full node-set rather
>than simply setting the context node to be the document root. This was
>necessary to the new transform processing model because the output is
>expected to be a full node-set (minus a few carefully omitted elements), so
>XPaths chained together (or an XPath after an enveloped signature transform)
>needed to take full node-sets as input. However, the result is quite lovely
>in that the required XPath expressions are simpler and almost always
>identical to the expressions one would write for an XSLT template match.
>
>8) I now distinguish between Canonical XML and Canonical XML with Comments.
>This was really quite necessary to get everything to work and keep all of
>the features we used to have. Canonical XML with Comments is recommended,
>not required. As well, it seemed like it wouldn't hurt anything because
>Minimal canonicalization would be quite difficult if comments had to be
>omitted.
>
>9) The C14N Draft needs to be changed. Rather than taking an octet stream
>representing the document plus taking an optional XPath expression to filter
>the document, it will now take an octet stream or node-set as input, along
>with an optional flag that tells whether or not comments should be omitted
>from the output. For the octet stream case (which is the one everyone's
>really focused on right now), the stream will be converted to a node-set AS
>CURRENTLY DEFINED as long as the comment flag is FALSE. The identifier (URL
>for C14N)#WithComments will be created within the C14N document.
>
>Thanks,
>
> John Boyer
> Development Team Leader,
> Distributed Processing and XML
> PureEdge Solutions Inc.
> Creating Binding E-Commerce
> v: 250-479-8334, ext. 143 f: 250-479-3772
> 1-888-517-2675 http://www.PureEdge.com
>
>
>
>
>------=_NextPart_002_0040_01C00C3C.6DC37130
>Content-Type: text/html;
> charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
><HTML><HEAD>
><META content=3D"text/html; charset=3Diso-8859-1" =
>http-equiv=3DContent-Type>
><META content=3D"MSHTML 5.00.3018.900" name=3DGENERATOR></HEAD>
><BODY>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>Hello=20
>all,</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN =
>class=3D590533919-22082000>Attached is a copy=20
>of the latest editors' copy of the XML DSig specification, except that I =
>have=20
>added and deleted the text necessary to implement the new=20
>Reference/Transform processing model discussed in the most recent=20
>teleconference. </SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>The =
>sections of HTML=20
>surrounded by <u></u> and <strike></strike> were =
>added=20
>by the editors prior to my receiving the document. The sections =
>surrounded=20
>by <u john=3D"john"></u> and <strike =
>john=3D"john"></strike>=20
>reflect the modifications I made. There turns out to be =
>quite a large=20
>number of changes, so I would ask as many of you as possible to really =
>read over=20
>the new document, esp. the content appearing in underlined red (though =
>that text=20
>is a mix of my additions and the former additions by the=20
>editors).</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN =
>class=3D590533919-22082000>Despite the large=20
>number of changes, I have tried to change the behavior of as few things =
>as=20
>humanly possible. Below is a manifest of the things I can recall=20
>changing:</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>1) =
>Obviously the=20
>changes have fixed the enveloped signature transform. =
></SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>2) =
>Removed=20
>requirement for barename XPointer support from external resources. =
>We=20
>nevery really had this support, we just really haven't acknowledged it=20
>before. Also, I glommed onto the definition of same-document =
>reference=20
>from RFC2396 as the way to distinguish when we do require barename =
>XPointer=20
>support. Same-document reference covers the null URI plus URIs =
>that=20
>essentially start with a #.</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>NOTE: =
>We could=20
>recover id processing by adding a REQUIRED 'id' transform that =
>performs the=20
>same function as the xpointer I defined in the text. If we do =
>that, then=20
>I'd say for the sake of consistency that the other xpointer I defined =
>should be=20
>done as a transform too, as well as the notion of null URI (which =
>excludes=20
>comments). The point of these other two is to make sure we can =
>convert=20
>from octet streams to node-sets with or without comments. As =
>well,=20
>the three ideas may be expressible as a single Transform with a =
>parameter. I'd=20
>be happy to take a stab at writing this up if the WG would=20
>like.</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>3) =
>Added idea that=20
>same-document URIs in the Reference would result in a location-set, then =
>defined=20
>how to boil the location-set down to an XPath node-set (which is pretty =
>easy=20
>considering an XPointer location set is a node-set except for the =
>addition of=20
>point and range ndoes). BTW, the new text is careful to say 'XPath =
>
>node-set (or sufficiently functional alternative)' or words to that =
>effect=20
>throughout the document.</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>4) =
>Rewrote text of=20
>all Transforms such that they indicate whether they input and output an =
>octet=20
>stream or a node-set. Rewrote text surrounding DigestMethod so =
>that it is=20
>clear that if the input is not an octet stream, then the node-set gets=20
>canonicalized.</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>5) =
>Rewrote material=20
>around how to generate textual input for SignatureMethod. =
>Basically, made=20
>it clear that SignedInfo is canonicalized within the context of the =
>surrounding=20
>document, which was not previously stated.</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>6) As =
>a result of=20
>the new processing model, it was possible to upgrade the behavior of the =
>base 64=20
>transform so that it automatically strips away the start and end tags if =
>the=20
>base 64 content is within XML. (Being able to do this on XML elements =
>derived=20
>from external resources would be a great reason to have a transform =
>that=20
>does 'id' resolution).</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>7) =
>Changed XPath so=20
>that it iterates on all nodes in a full node-set rather than simply =
>setting the=20
>context node to be the document root. This was necessary to the =
>new=20
>transform processing model because the output is expected to be a full =
>node-set=20
>(minus a few carefully omitted elements), so XPaths chained =
>together (or an=20
>XPath after an enveloped signature transform) needed to take full =
>node-sets as=20
>input. However, the result is quite lovely in that the required =
>XPath=20
>expressions are simpler and almost always identical to the expressions =
>one would=20
>write for an XSLT template match.</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>8) I =
>now distinguish=20
>between Canonical XML and Canonical XML with Comments. This was =
>really=20
>quite necessary to get everything to work and keep all of the features =
>we used=20
>to have. Canonical XML with Comments is recommended, not =
>required. =20
>As well, it seemed like it wouldn't hurt anything because Minimal=20
>canonicalization would be quite difficult if comments had to be=20
>omitted.</SPAN></FONT></DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000></SPAN></FONT> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D590533919-22082000>9) The =
>C14N Draft=20
>needs to be changed. Rather than taking an octet stream representing the =
>
>document plus taking an optional XPath expression to filter the =
>document, it=20
>will now take an octet stream or node-set as input, along with an =
>optional flag=20
>that tells whether or not comments should be omitted from the =
>output. For=20
>the octet stream case (which is the one everyone's really focused on =
>right now),=20
>the stream will be converted to a node-set AS CURRENTLY DEFINED as long =
>as the=20
>comment flag is FALSE. The identifier (URL for C14N)#WithComments =
>will be=20
>created within the C14N document.</SPAN></FONT></DIV>
><DIV> </DIV>
><DIV><FONT face=3DArial size=3D2><SPAN=20
>class=3D590533919-22082000>Thanks,</SPAN></FONT></DIV>
><TABLE border=3D0 cellPadding=3D0 cellSpacing=3D0 width=3D420>
> <TBODY>
> <TR bgColor=3D#ffffff>
> <TD colSpan=3D2><IMG height=3D2 src=3D"cid:590533919@22082000-2d36" =
>width=3D400>=20
> </TD></TR>
> <TR>
> <TD width=3D95><IMG border=3D0 height=3D78 =
>src=3D"cid:590533919@22082000-2d3d"=20
> width=3D86></TD>
> <TD><FONT color=3D#0066cc face=3D"Verdana, Arial, Helvetica, =
>sans-serif"=20
> size=3D1>John Boyer<BR>Development Team Leader,<BR>Distributed =
>Processing=20
> and XML <BR></FONT><FONT face=3D"Verdana, Arial, Helvetica, =
>sans-serif"=20
> size=3D1><B>PureEdge Solutions Inc. <BR><FONT =
>color=3D#000000>Creating Binding=20
> E-Commerce</FONT><BR></B><FONT color=3D#0066cc>v: 250-479-8334, =
>ext.=20
> 143 f: 250-479-3772<BR>1-888-517-2675 <A=20
> =
>href=3D"http://www.pureedge.com/"><B>http://www.PureEdge.com</B></A>=20
> </FONT></FONT></TD></TR>
> <TR>
> <TD colSpan=3D2><IMG height=3D2 src=3D"cid:590533919@22082000-2d36" =
>width=3D400>=20
> </TD></TR></TBODY></TABLE>
><DIV> </DIV></BODY></HTML>
>
>------=_NextPart_002_0040_01C00C3C.6DC37130--
>
>------=_NextPart_001_003F_01C00C3C.6DC37130
>Content-Type: image/gif;
> name="LINE.gif"
>Content-Transfer-Encoding: base64
>Content-ID: <590533919@22082000-2d36>
>
>R0lGODlhkAECAJH/AAAAAP///8zMAP///ywAAAAAkAECAAACGpSPqcvtD6OctNqLs968+w+G4kiW
>5omm6ooVADs=
>
>------=_NextPart_001_003F_01C00C3C.6DC37130
>Content-Type: image/jpeg;
> name="PureEdge.jpg"
>Content-Transfer-Encoding: base64
>Content-ID: <590533919@22082000-2d3d>
>
>/9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH
>BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8
>SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7
>Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABOAFYDASIAAhEBAxEB/8QAHAABAAIDAQEBAAAAAAAAAAAA
>AAYHAgUIBAED/8QAMxAAAQMDAQcDAwMDBQAAAAAAAQIDBAAFEQYHEhMhMUFRYXGxImKBFDLSFRYj
>QqHBwvD/xAAZAQEBAQEBAQAAAAAAAAAAAAAABAMCAQX/xAAnEQACAgEDAwMFAQAAAAAAAAAAAQID
>EQQTMRIhQVFhsSJxgaHB8P/dAAQAKP/aAAwDAQACEQMRAD8AualKUArFSkoQVrUEpSMkk4AFFrS2
>hS1qCUpGVKUcADzVDbUNqKr2t2x2J4ptyTuvyEnBkHwPs+fagM9pu1Ry6vLs2npCm4LasPSmyQp8
>jsk9k/Pt18TG1K9Xq1xbVLk8J1nGX2yUrfI6bx8j/eq4oCQcg4IruuXRJSwZ2w3IOOcHTWidbt3x
>tMCepKLggfSegeHkevkf+Eyrlmx3xanG23HS3IQQW3AcEkdOfmrz0TrdF7bTb7gtKJ6B9KjyD48j
>7vSt7alJblfHwS03SjLat58P1JnSlKlLhSlKAVitaW0KWtQShIypSjgAeTRSkoQVrUEpSMkk4AFU
>JtS2nLvjrljsj+Lag4eeQcGSfA+z59qAbT9qK76tyyWN1SLak7rz6eRknwPs+arClKAUpSgAJByD
>gipJZL6pTjbbrhQ+ggtug4JI6c/NR1DTjmeGhS90ZO6M4FY1rVbKt5RjdTG2OGdMaI1ui9Npt1xW
>ET0j6VnkHh/L0qaVyvY72srQ064UPIILbgOCSOnPzV56I1wi8oRbrisInpGELPIPj+Xp3rWypSju
>V8fBPTdKMtq3nw/UmtKUqUuKJ2l7TnLxNVp+zLU3AQ5uSXuhkEHmkeE/Pt19l4t1qacmouEC1MW1
>MbeQ4lKUPBz0xW72m7MU3nfv1iZSm5N/W8wOQk47j7/n3qldQXiXfLqqXNZQy8lIbUhCSMY9D3r5
>2r0s77INPCWf4dxkkjcN6G4l7t9t/qWP1sT9TxOB+zkTu43ufTrmvz/s5lNmiT3LuhtyZvpZYLJy
>twHASCD38nGOXWvsXX1wjRWUCFDckx2eC1KW2S4lOMdc1qZd+ly4FviKCEC3lRaWkHeJUQcn8iuI
>R1zklKWF+Pf2+w+kkM7Z87AiOvpml1+KkLdbLJShQ77qs88e1WFtOhAwRabcrT7KpYYbRFKEpmKW
>pwAFOP8AT07djVVTtYSbgw4HbdAEl4AOygz/AJFAe/IH2rZ3najer2wEyINrbfSUFuU1GIebKFBS
>d1RUccxVOkWoUHvvL/3oeSx4JzpjSNu0m7qOK1qFqfcUWd1MqKlgo4RIByCSQodvyKjkPZLEcl2+
>1T9UNw7zNY4/6MRC5uIwTje3gCeR8dD+fG/tduz7com0WlEibHLEmShghx0EYyTnsPxU2sWurIxE
>ttzuN/t8lcSIUOcWCROzggICskEZPUdfyTVZyRSz7IHp9tZlybqqM5KWsRgiKVpAScBTisjdBx69
>a0cKbJhXN61y1lMyG6pviIPVSDg8/PLrXog7Qp5ZagO2a23QMOuKhGYxvqY3jkjqAR71+9isMq4X
>LhsNJeny1lSyhISlOTk4A5JSKr0qn1ZXHkh1rh0dL7vwWzo3XrVximJdnOHKZTni45Op6ZOOhpW6
>0tpWJpqDuIw7KcH+Z7HX0HgUrKx1uT6V2NqY2qCU33N9VYbT9l6L+hy92RoIuaRl5lPISR5H3/NW
>fSsSg40WhbTim3EqQtJIUlQwQfBr5V/7T9l6NQNuXqytJRc0DLrKRgSR/P5qgnG1suKbcQpC0EpU
>lQwQR1BFAY0pSgFZssuPupaaSVLUeQFGWXJDqWmklS1HkBU30vpeRKlNwoTXGlO/vX2SO5J7AVtV
>U7Hl9kT33qpYXdvhGOmtNPvyW4cNrjy3uqh0SO/PsBV76W0tE01B3G8OSnAOM+RzUfA8CstM6Xha
>ahcNkcSQ4BxnyOaj4Hgelbuu7bk10Q4OKKHF7lneT/QpSlTFYpSlAKrHalsyTf2l3uyMpTc0DLzS
>eQkgf9/mrOpQHGi0KbWpC0lKknCkqGCD4rJllyQ6lppJUtXQCr12sbOYlxiu6jt5bizG8GQkjCHg
>SBnl0Vz6968cjZK1YLBGkRpgcnFSUSVL5IUVEAbvLIAJ/PX0rSuKlJJsyum4QckskM0zpl+TKbhQ
>muNKd/crskd+fYCr50zpqJpu3BhkBb6wC89jms/8DwKaZ0xE01A4LOHJC8F54jms+B4HpW6rW61N
>dEOEY0UOL3LO8mKUpUxWKUpQH//Z
>
>------=_NextPart_001_003F_01C00C3C.6DC37130--
>
>------=_NextPart_000_003E_01C00C3C.6DC37130
>Content-Type: text/html;
> name="Overview.html"
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: attachment;
> filename="Overview.html"
>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
><html xmlns=3D"http://www.w3.org/1999/xhtml">
>
><head>
><meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 3.0" />
><meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 3.0" />
><meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 3.0" />
><meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 3.0" />
><meta http-equiv=3D"Content-Type" content=3D"text/html; =
>charset=3Diso-8859-1" />
><style type=3D"text/css">
>
>CODE {
> FONT-FAMILY: monospace; =20
> FONT-WEIGHT: normal
>}
>
>u {=20
> color: red;
>}
>
>strike {
> color: silver;
>}
>
>.ietf {
> DISPLAY: none;=20
> FONT-FAMILY: monospace;=20
> FONT-SIZE: 100%;=20
> FONT-WEIGHT: normal
>}
>
>.discuss {
> COLOR: red
>}
>.link-def {
> COLOR: teal;
> FONT-STYLE: italic
>}
>
>.comment {
> BACKGROUND-COLOR: #fffff5;=20
> BORDER-BOTTOM: navy thin solid;
> BORDER-LEFT: navy thin solid;=20
> BORDER-RIGHT: navy thin solid;=20
> BORDER-TOP: navy thin solid
>}
>
>.xml-example {
> font-size: 90%;=20
> font-family: monospace;=20
> letter-spacing: normal;=20
> line-height: normal;=20
> text-indent: 0px;=20
> text-indent: 0px;=20
> margin-left: -1em;=20
> margin-right: 0em
>}
>
>.xml-dtd {
> background-color: rgb(239,239,248);=20
> font-size: 90%;=20
> font-family: monospace;=20
> letter-spacing: normal;=20
> line-height: normal;=20
> text-indent: 0px;=20
> text-indent: 0px;=20
> margin-left: -1em;=20
> margin-right: 0em
>}
>.term {
> BACKGROUND-COLOR: yellow;=20
> FONT-WEIGHT: bold
>}
>
></style>
><title>XML-Signature Syntax and Processing</title>
><link rel=3D"stylesheet" type=3D"text/css" =
>href=3D"http://www.w3.org/StyleSheets/TR/W3C-WD.css"
>/>
></head>
>
><body>
>
><p> <a href=3D"http://www.ietf.org"><img
>src=3D"http://ietf.org/images/ietflogo2e.gif" alt=3D"IETF Logo" =
>border=3D"0" height=3D"48"
>width=3D"92" /></a><a href=3D"http://www.w3.org/"><img =
>src=3D"http://www.w3.org/Icons/w3c_home"
>alt=3D"W3C Logo" border=3D"0" height=3D"48" width=3D"72" /></a></p>
><div class=3D"head">
>
><h1 class=3D"notoc">XML-Signature Syntax and Processing</h1>
>
><h2 class=3D"notoc">W3C Working Draft xx-AAAA-2000</h2>
>
><dl>
> <dt>This version:</dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/">http://www.w=
>3.org/Signature/Drafts/WD-xmldsig-core-latest/</a></dd>
> <dt>Latest version:</dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/xmldsig-core/">http://www.w3.org/TR/xmldsig-=
>core/</a></dd>
> <dt>Previous version:</dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/">http://www.w=
>3.org/TR/2000/WD-xmldsig-core-20000711/</a><br>
> <a =
>href=3D"http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-core-08.tx=
>t">http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-core-08.txt</a>=
>
> [<a
> =
>href=3D"http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/draft-ietf-xml=
>dsig-core-08.txt">W3C-mirror</a>]</dd>
> <dt>Editors</dt>
> <dd>Donald Eastlake <<a =
>href=3D"mailto:dee3@torque.pothole.com">dee3@torque.pothole.com</a>><b=
>r
> />
> Joseph Reagle <<a =
>href=3D"mailto:reagle@w3.org">reagle@w3.org</a>><br />
> David Solo <<a =
>href=3D"mailto:dsolo@alum.mit.edu">dsolo@alum.mit.edu</a>></dd>
> <dt>Authors</dt>
> <dd>Mark Bartel <<a =
>href=3D"mailto:mbartel@JetForm.com">mbartel@JetForm.com</a>></dd>
> <dd>John Boyer <<a =
>href=3D"mailto:jboyer@PureEdge.com">jboyer@PureEdge.com</a>><br />
> Barb Fox <<a =
>href=3D"mailto:bfox@Exchange.Microsoft.com">bfox@Exchange.Microsoft.com</=
>a>></dd>
> <dd>Ed Simon <<a =
>href=3D"mailto:ed.simon@entrust.com">ed.simon@entrust.com</a>></dd>
> <dt>Contributors</dt>
> <dd>See <a href=3D"#_Acknowledgements">Acknowledgements</a></dd>
></dl>
>
><p class=3D"copyright"><a =
>href=3D"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyrigh=
>t</a>
>=A9 2000 <a href=3D"http://www.w3.org/"><abbr title=3D"World Wide Web =
>Consortium">W3C</abbr></a><sup>=AE</sup> (<a
>href=3D"http://www.lcs.mit.edu/"><abbr title=3D"Massachusetts Institute =
>of Technology">MIT</abbr></a>, <a href=3D"http://www.inria.fr/"><abbr =
>lang=3D"fr" title=3D"Institut National de Recherche en Informatique et =
>Automatique"> INRIA</abbr></a>, <a
>href=3D"http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
>href=3D"http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">l=
>iability</a>, <a
>href=3D"http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">tra=
>demark</a>, <a
>href=3D"http://www.w3.org/Consortium/Legal/copyright-documents-19990405">=
>document use</a>
>and <a =
>href=3D"http://www.w3.org/Consortium/Legal/copyright-software-19980720">s=
>oftware
>licensing</a> rules apply.</p>
>
><hr title=3D"Separator from Header" />
></div>
>
><h2 class=3D"notoc">Abstract</h2>
>
><p>This document specifies XML digital signature processing rules and =
>syntax. XML
>Signatures provide integrity, message authentication, and/or signer =
>authentication
>services for data of any type, whether located within the XML that =
>includes the signature
>or elsewhere.</p>
>
><h2 class=3D"notoc"><a id=3D"status" name=3D"status"></a>Status of this =
>document</h2>
>
><p class=3D"notoc">This is an editors version used to track the latest =
>comments/suggestions.
>This version <u>highlights</u> (via red underlined text) a few of the =
>changes from the
>previous version. You shouldn't implement this, and you shouldn't even =
>really read it.
>This may not even include all the tweaks that are present on a editors' =
>local version.</p>
>
><p><strike>Please send comments to the editors and cc: the list <<a
>href=3D"mailto:w3c-ietf-xmldsig@w3.org">w3c-ietf-xmldsig@w3.org</a>>. =
>Publication as a
>Working Draft does not imply endorsement by the W3C membership or IESG. =
>It is
>inappropriate to cite W3C Drafts as other than "work in =
>progress." A list of
>current W3C working drafts can be found at <a =
>href=3D"http://www.w3.org/TR/">http://www.w3.org/TR/</a>.
>Current IETF drafts can be found at <a =
>href=3D"http://www.ietf.org/1id-abstracts.html">http://www.ietf.org/1id-a=
>bstracts.html</a>.</strike></p>
>
><p><strike>Patent disclosures relevant to this specification may be =
>found on the Working
>Group's <a href=3D"http://www.w3.org/Signature/Disclosures.html">patent =
>disclosure page</a>
>and IETF's <a href=3D"http://www.ietf.org/ipr.html">Intellectual =
>Property Right Notices</a>.</strike></p>
>
><h2>Table of Contents</h2>
>
><ol>
> <li><a href=3D"#sec-Introduction">Introduction</a> <ol>
> <li><a href=3D"#sec-Editorial">Editorial Conventions</a></li>
> <li><a href=3D"#sec-Design">Design Philosophy</a></li>
> <li><a href=3D"#sec-Versions">Versions, Namespaces and =
>Identifiers</a></li>
> <li><a href=3D"#sec-Acknowledgements">Acknowledgements</a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-Overview">Signature Overview and Examples</a> <ol>
> <li><a href=3D"#sec-o-SignatureProperty">Simple Example =
>(<code>Signature</code>, <code>SignedInfo</code>,
> <code>Methods</code>, and <code>References</code></a>) <ol>
> <li><a href=3D"#sec-o-Reference">More on =
><code>Reference</code></a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-o-SignatureProperty">Extended Example =
>(<code>Object</code> and <code>SignatureProperty</code>)</a></li>
> <li><a href=3D"#sec-o-Manifest">Extended Example =
>(<code>Object</code> and <code>Manifest</code>)</a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-Processing">Processing Rules</a> <ol>
> <li><a href=3D"#sec-CoreGeneration">Signature Generation</a></li>
> <li><a href=3D"#sec-CoreValidation">Signature Validation</a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-CoreSyntax">Core Signature Syntax</a> <ol>
> <li><a href=3D"#sec-Signature">The <code>Signature</code> =
>element</a></li>
> <li><a href=3D"#sec-SignatureValue">The =
><code>SignatureValue</code> Element</a></li>
> <li><a href=3D"#sec-SignedInfo">The <code>SignedInfo</code> =
>Element</a> <ol>
> <li><a href=3D"#sec-CanonicalizationMethod">The =
><code>CanonicalizationMethod</code> Element</a></li>
> <li><a href=3D"#sec-SignatureMethod">The =
><code>SignatureMethod</code> Element</a></li>
> <li><a href=3D"#sec-Reference">The <code>Reference</code> =
>Element</a> <ol>
> <li><a href=3D"#sec-Transforms">The =
><code>Transforms</code> Element</a></li>
> <li><a href=3D"#sec-DigestMethod">The =
><code>DigestMethod</code> Element</a></li>
> <li><a href=3D"#sec-DigestValue">The =
><code>DigestValue</code> Element</a></li>
> </ol>
> </li>
> </ol>
> </li>
> <li><a href=3D"#sec-KeyInfo">The <code>KeyInfo</code> =
>Element</a></li>
> <li><a href=3D"#sec-Object">The <code>Object</code> =
>Element</a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-AdditionalSyntax">Additional Signature Syntax</a> =
><ol>
> <li><a href=3D"#sec-Manifest">The <code>Manifest</code> =
>Element</a></li>
> <li><a href=3D"#sec-SignatureProperties">The =
><code>SignatureProperties</code> Element</a></li>
> <li><a href=3D"#sec-PI">Processing Instructions</a></li>
> <li><a href=3D"#sec-comments">Comments in dsig Elements</a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-Algorithms">Algorithms</a> <ol>
> <li><a href=3D"#sec-AlgID">Algorithm Identifiers and =
>Implementation Requirements</a></li>
> <li><a href=3D"#sec-MessageDigests">Message Digests</a></li>
> <li><a href=3D"#sec-MACs">Message Authentication Codes</a></li>
> <li><a href=3D"#sec-SignatureAlg">Signature Algorithms</a></li>
> <li><a href=3D"#sec-c14nAlg">Canonicalization Algorithms</a></li>
> <li><a href=3D"#sec-TransformAlg">Transform Algorithms</a> <ol>
> <li><a =
>href=3D"#sec-Canonicalization">Canonicalization</a></li>
> <li><a href=3D"#sec-Base-64">Base64</a></li>
> <li><a href=3D"#sec-XPath">XPath Filtering</a></li>
> <li><a href=3D"#sec-EnvelopedSignature">Enveloped Signature =
>Transform</a></li>
> <li><a href=3D"#sec-XSLT">XSLT Transform</a></li>
> </ol>
> </li>
> </ol>
> </li>
> <li><a href=3D"#sec-XML-Canonicalization">XML Canonicalization and =
>Syntax Constraint
> Considerations</a> <ol>
> <li><a href=3D"#sec-XML-1">XML 1.0, Syntax Constraints, and =
>Canonicalization</a></li>
> <li><a href=3D"#sec-DOM-SAX">DOM/SAX Processing and =
>Canonicalization</a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-Security">Security Considerations</a> <ol>
> <li><a href=3D"#sec-Security-Transofrms">Transforms</a> <ol>
> <li><a href=3D"#sec-Secure">Only What is Signed is =
>Secure</a></li>
> <li><a href=3D"#sec-Seen">Only What is "Seen" Should =
>be Signed</a></li>
> <li><a href=3D"#sec-See">"See" What is =
>Signed</a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-Check">Check the Security Model</a></li>
> <li><a href=3D"#sec-KeyLength">Algorithms, Key Lengths, =
>Etc.</a></li>
> </ol>
> </li>
> <li><a href=3D"#sec-Schema">Schema, DTD, Data Model,and Valid =
>Examples</a></li>
> <li><a href=3D"#sec-Definitions">Definitions</a></li>
> <li><a href=3D"#sec-References">References</a></li>
> <li><a href=3D"#sec-Authors">Authors' Address</a></li>
></ol>
>
><hr />
>
><h2>1.0 <a id=3D"sec-Introduction" =
>name=3D"sec-Introduction">Introduction</a></h2>
>
><p>This document specifies XML syntax and processing rules for creating =
>and representing
>digital signatures. XML Signatures can be applied to any <a =
>href=3D"#def-DataObject"
>class=3D"link-def">digital content (data object)</a>, including XML. An =
>XML Signature may be
>applied to the content of one or more resources. <a =
>href=3D"#def-SignatureEnveloped"
>class=3D"link-def">Enveloped</a> or <a href=3D"#def-SignatureEnveloping" =
>class=3D"link-def">enveloping</a>
>signatures are over data within the same XML document as the signature; =
><a
>href=3D"#def-SignatureDetached" class=3D"link-def">detached</a> =
>signatures are over
>data external to the signature element. <u>More specifically, this =
>specification
>defines an XML signature element type and an XML Signature application; =
>conformance
>requirements for each are specified by way of schema definitions and =
>prose respectively.
>This specification also includes other useful types that identify =
>methods for referencing
>collections of resources, algorithms, and keying and management =
>information.</u></p>
>
><p><u>The XML Signature is a method of associating a key with referenced =
>data (octets); it
>does not normatively specify how keys are associated with persons or =
>institutions, nor the
>meaning of the data being referenced and signed. Consequently, while =
>this specification is
>an important component of secure XML applications, it itself is not =
>sufficient to address
>all application security/trust concerns, particularly with respect to =
>using signed XML (or
>other data formats) as a basis of human-to-human communication and =
>agreement. Such an
>application must specify additional key, algorithm, processing and =
>rendering requirements.
>For further information, please see Section 8: </u><a =
>href=3D"#sec-Security">Security
>Considerations</a><u>.</u></p>
>
><h3>1.1 <a id=3D"sec-Editorial" name=3D"sec-Editorial">Editorial</a> =
>Conventions</h3>
>
><p>For readability, brevity, and historic reasons this document uses the =
>term
>"signature" to generally refer to digital authentication =
>values of all
>types.Obviously, the term is also strictly used to refer to =
>authentication values that are
>based on public keys and that provide signer authentication. When =
>specifically discussing
>authentication values based on symmetric secret key codes we use the =
>terms authenticators
>or authentication codes. (See section 8.3:<a href=3D"#sec-Check">Check =
>the Security Model</a>.)</p>
>
><p>This specification uses both XML Schemas [<a =
>href=3D"#ref-XML-schema">XML-schema</a>] and
>DTDs [<a href=3D"#ref-XML">XML</a>]. (Readers unfamiliar with DTD syntax =
>may wish to refer
>to Ron Bourret's " <a
>href=3D"http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/xmld=
>td.html">Declaring
>Elements and Attributes in an XML DTD</a>" [<a =
>href=3D"#ref-Bourret">Bourret</a>].) The
>schema definition is presently normative. <u>Consequently, Signature =
>element instances
>MUST be <a =
>href=3D"http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#cvc-elt-lax">l=
>axly
>schema valid</a> [<a href=3D"#ref-XML-schema">XML-schema</a>].</u></p>
>
><p>The key words "MUST", "MUST NOT", =
>"REQUIRED",
>"SHALL", "SHALL NOT", "SHOULD", =
>"SHOULD NOT",
>"RECOMMENDED", "MAY", and "OPTIONAL" in =
>this specification
>are to be interpreted as described in <a =
>href=3D"http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a>
>[<a href=3D"#ref-KEYWORDS">KEYWORDS</a>]:</p>
>
><blockquote>
> <p>"they MUST only be used where it is actually required for =
>interoperation or to
> limit behavior which has potential for causing harm (e.g., limiting =
>retransmissions)"</p>
></blockquote>
>
><p>Consequently, we use these capitalized keywords to unambiguously =
>specify requirements
>over protocol and application features and behavior that affect the =
>interoperability and
>security of implementations. These key words are not used (capitalized) =
>to describe XML
>grammar; schema definitions unambiguously describe such requirements and =
>we wish to
>reserve the prominence of these terms for the natural language =
>descriptions of protocols
>and features. For instance, an XML attribute might be described as being
>"optional." Compliance with the XML-namespace specification =
>[<a
>href=3D"#ref-XML-ns">XML-ns</a>] is described as =
>"REQUIRED."</p>
>
><h3>1.2 <a id=3D"sec-Design" name=3D"sec-Design">Design</a> =
>Philosophy</h3>
>
><p>The design philosophy and requirements of this specification are =
>addressed in the
>XML-Signature Requirements document [<a =
>href=3D"#XML-Signature-RD">XML-Signature-RD</a>].</p>
>
><h3>1.3 <a id=3D"sec-Versions" name=3D"sec-Versions">Versions</a>, =
>Namespaces and Identifiers</h3>
>
><p>No provision is made for an explicit version number in this syntax. =
>If a future version
>is needed, it will use a different namespace The XML namespace [<a
>href=3D"#ref-XML-ns">XML-ns</a>] URI that MUST be used by =
>implementations of this (dated)
>specification is:</p>
>
><pre class=3D"xml-example">
> xmlns=3D"<u>http://www.w3.org/2000/07/xmldsig#</u>"
></pre>
>
><p>This namespace is also used as the prefix for algorithm identifiers =
>used by this
>specification. While applications MUST support XML and XML-namespaces, =
>the use of <a
>href=3D"http://www.w3.org/TR/REC-xml#sec-internal-ent">internal =
>entities</a> [<a
>href=3D"#ref-XML">XML</a>] or our "dsig" XML <a
>href=3D"http://www.w3.org/TR/1999/REC-xml-names-19990114/#dt-prefix">name=
>space prefix</a>
>and defaulting/scoping conventions are OPTIONAL; we use these facilities =
>to provide
>compact and readable examples.</p>
>
><p>This specification uses Uniform Resource Identifiers [<a =
>href=3D"#ref-URI">URI</a>]
>to identify resources, algorithms, and semantics. The URI in the =
>namespace declaration
>above is also used as a prefix for URIs under the control of this =
>specification. For
>resources not under the control of this specification, we use the =
>designated Uniform
>Resource Names [<a href=3D"#ref-URN">URN</a>] or Uniform Resource =
>Locators [<a
>href=3D"#ref-URL">URL</a>] defined by its normative external =
>specification. If an external
>specification has not allocated itself a Uniform Resource Identifier we =
>allocate an
>identifier under our own namespace. For instance:=20
>
><dl>
> <dt><span style=3D"font-weight: =
>normal"><code>SignatureProperties</code> is identified and
> defined by this specification's namespace</span></dt>
> <dd>http://www.w3.org/2000/07/xmldsig#<span style=3D"font-weight: =
>normal">SignatureProperties</span></dd>
> <dt><span style=3D"font-weight: normal">XSLT is identified and defined =
>by an external
> namespace</span></dt>
> <dd><span style=3D"font-weight: =
>normal">http://www.w3.org/TR/1999/PR-xslt-19991008</span></dd>
> <dt><span style=3D"font-weight: normal">SHA1 is identified via this =
>specification's namespace
> and defined via a normative reference</span></dt>
> <dd>http://www.w3.org/2000/07/xmldsig#<span style=3D"font-weight: =
>normal">sha1</span></dd>
> <dd><br />
> FIPS PUB 180-1. <i>Secure Hash Standard.</i> U.S. Department of =
>Commerce/National
> Institute of Standards and Technology.</dd>
></dl>
>
><p>Finally, in order to provide for terse namespace declarations we =
>sometimes use <a
>href=3D"http://www.w3.org/TR/REC-xml#sec-internal-ent">XML internal =
>entities</a> [<a
>href=3D"#ref-XML">XML</a>] as macros within URIs. For instance:</p>
>
><pre class=3D"xml-example">
> <?xml version=3D'1.0'?>
> <!DOCTYPE Signature SYSTEM=20
> "xmldsig-core-schema.dtd" [ <!ENTITY dsig
> "http://www.w3.org/2000/07/xmldsig#"> ]>
> <Signature xmlns=3D"&dsig;" =
>Id=3D"MyFirstSignature">
> <SignedInfo>
> ...
></pre>
>
><h3>1.4 <a id=3D"_Acknowledgements" =
>name=3D"_Acknowledgements"></a><a
>id=3D"sec-Acknowledgements" =
>name=3D"sec-Acknowledgements">Acknowledgements</a></h3>
>
><p>The contributions of the following working group members to this =
>specification are
>gratefully acknowledged:=20
>
><ul>
> <li>Mark Bartel, JetForm Corporation (Author)</li>
> <li>John Boyer, PureEdge (Author)</li>
> <li>Mariano P. Consens, University of Waterloo</li>
> <li>John Cowan, Reuters Health</li>
> <li>Donald Eastlake 3rd, Motorola (Chair, Author/Editor)</li>
> <li>Barb Fox, Microsoft (Author)</li>
> <li>Christian Geuer-Pollmann, University Siegen</li>
> <li>Tom Gindin, IBM</li>
> <li>Phillip Hallam-Baker, VeriSign Inc</li>
> <li>Richard Himes, US Courts</li>
> <li>Gregor Karlinger, IAIK TU Graz</li>
> <li>Brian LaMacchia, Microsoft</li>
> <li>Peter Lipp, IAIK TU Graz</li>
> <li>Joseph Reagle, W3C (Chair, Author/Editor)</li>
> <li>Ed Simon, Entrust Technologies Inc. (Author)</li>
> <li>David Solo, Citigroup (Author/Editor)</li>
> <li>Petteri Stenius, DONE Information, Ltd</li>
> <li>Raghavan Srinivas, Sun</li>
> <li>Kent Tamura, IBM</li>
> <li>Winchel Todd Vincent III, GSU</li>
> <li>Carl Wallace, Corsec Security, Inc.</li>
> <li>Greg Whitehead, Signio Inc.</li>
></ul>
>
><p>As are the last call comments from the following:=20
>
><ul>
> <li>Dan Connolly, W3C</li>
> <li>Paul Biron, Kaiser Permanente, on behalf of the <a
> href=3D"http://www.w3.org/XML/Schema.html">XML Schema WG</a>.</li>
> <li>Martin J. Duerst, W3C; and Masahiro Sekiguchi, Fujitsu; on behalf =
>of the <a
> href=3D"http://www.w3.org/International/">Internationalization =
>WG/IG</a>.</li>
> <li>Jonathan Marsh, Microsoft, on behalf of the <a =
>href=3D"http://www.w3.org/Style/XSL/">Extensible
> Stylesheet Language WG</a>.</li>
></ul>
>
><h2>2.0 <a id=3D"sec-Overview" name=3D"sec-Overview">Signature =
>Overview</a> and Examples</h2>
>
><p>This section provides an overview and examples of XML digital =
>signature syntax. The
>specific processing is given in section 3: <a
>href=3D"http://www.w3.org/TR/2000/WD-xmldsig-core-20000104/#sec-Processin=
>g">Processing Rules</a>.
>The formal syntax is found in section 4: <a =
>href=3D"#sec-CoreSyntax">Core Signature Syntax</a>
>and section 5: <a href=3D"#sec-AdditionalSyntax">Additional Signature =
>Syntax</a>.</p>
>
><p>In this section, an informal representation and examples are =
>used to describe the
>structure of the XML signature syntax. This representation and examples =
>may omit
>attributes, details and potential features that are fully explained =
>later.</p>
>
><p>XML Signatures are applied to arbitrary <a href=3D"#def-DataObject" =
>class=3D"link-def">digital
>content (data objects)</a> via an indirection. Data objects are =
>digested, the resulting
>value is placed in an element (with other information) and that element =
>is then digested
>and cryptographically signed. XML digital signatures are represented by =
>the <code>Signature</code>
>element which has the following structure (where "?" denotes =
>zero or one
>occurrence; "+" denotes one or more occurrences; and =
>"*" denotes zero
>or more occurrences):</p>
>
><pre class=3D"xml-example">
> <Signature>=20
> <SignedInfo>
> (CanonicalizationMethod)
> (SignatureMethod)
> <u>(</u><Reference (URI=3D)? >
> (Transforms)?
> (DigestMethod)
> (DigestValue)
> </Reference>)+
> </SignedInfo>
> (SignatureValue)=20
> (KeyInfo)?
> (Object)*
> </Signature>
></pre>
>
><p>The content that is signed was, at the time of signature creation, =
>referred to as an
>identified <a href=3D"#def-Resource" class=3D"link-def">resource</a> to =
>which the specified
>transforms were applied.</p>
>
><p>Signatures are related to data objects via URIs [<a =
>href=3D"#ref-URI">URI</a>]. Within an
>XML document, signatures are related to local data objects via fragment =
>identifiers. Such
>local data can be included within an <a =
>href=3D"#def-SignatureEnveloping" class=3D"link-def">enveloping</a>
>signature or can enclose an <a href=3D"#def-SignatureEnveloped" =
>class=3D"link-def">enveloped</a>
>signature. <a href=3D"#def-SignatureDetached" =
>class=3D"link-def">Detached signatures</a> are
>over external network resources or local data objects that resides =
>within the same XML
>document as sibling elements; in this case, the signature is neither =
>enveloping (signature
>is parent) nor enveloped (signature is child). Since a =
><code>Signature</code> element (and
>its <code>Id</code> attribute value/name) may co-exist or be combined =
>with other elements
>(and their IDs) within a single XML document, care should be taken in =
>choosing names such
>that there are no subsequent collisions that violate the <a
>href=3D"http://www.w3.org/TR/REC-xml#id">ID uniqueness validity =
>constraint</a> [<a
>href=3D"#ref-XML">XML</a>].</p>
>
><h3>2.1 <a id=3D"sec-o-Simple" name=3D"sec-o-Simple">Simple Example</a> =
>(<code>Signature</code>,
><code>SignedInfo</code>, <code>Methods</code>, and =
><code>References</code>)</h3>
>
><p>The following example is a detached signature of the content of the =
>HTML4 in XML
>specification.</p>
>
><pre class=3D"xml-example">
> [s01] <Signature Id=3D"MyFirstSignature" =
>xmlns=3D"http://www.w3.org/2000/07/xmldsig#">=20
> [s02] <SignedInfo>=20
> [s03] <CanonicalizationMethod =
>Algorithm=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/&g=
>t;=20
> [s04] <SignatureMethod =
>Algorithm=3D"http://www.w3.org/2000/07/xmldsig#dsa-sha1"/>=20
> [s05] <Reference =
>URI=3D"http://www.w3.org/TR/2000/REC-xhtml1-20000126/">=20
> [s06] <Transforms>=20
> [s07] <Transform =
>Algorithm=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/&g=
>t;=20
> [s08] </Transforms>=20
> [s09] <DigestMethod =
>Algorithm=3D"http://www.w3.org/2000/07/xmldsig#sha1"/>=20
> [s10] =
><DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=3D</DigestValue>=20
> [s11] </Reference>=20
> [s12] </SignedInfo>=20
> [s13] =
><SignatureValue>MC0CFFrVLtRlk=3D...</SignatureValue>=20
> [s14] <KeyInfo>=20
> [s15a] <KeyValue>
> [s15b] <DSAKeyValue>=20
> [s15c] =
><P>...</P><Q>...</Q><G>...</G><Y&g=
>t;...</Y>=20
> [s15d] </DSAKeyValue>=20
> [s15e] </KeyValue>=20
> [s16] </KeyInfo>=20
> [s17] </Signature>
></pre>
>
><p><code>[s02-12]</code> The required <code>SignedInfo</code> element is =
>the information
>that is actually signed. <a href=3D"#def-ValidationCore" =
>class=3D"link-def">Core validation</a>
>of <code>SignedInfo</code> consists of two mandatory processes: <a
>href=3D"#def-ValidationSignature" class=3D"link-def">validation of the =
>signature</a> over <code>SignedInfo</code>
>and <a href=3D"#def-ValidationReference" class=3D"link-def">validation =
>of each <code>Reference</code></a>
>digest within <code>SignedInfo</code>. Note that the algorithms used in =
>calculating the <code>SignatureValue</code>
>are also included in the signed information while the =
><code>SignatureValue</code> element
>is outside <code>SignedInfo</code>.</p>
>
><p><code>[s03]</code> The <code>CanonicalizationMethod</code> is the =
>algorithm that is
>used to canonicalize the <code>SignedInfo</code> element before it is =
>digested as part of
>the signature operation. </p>
>
><p><code>[s04]</code> The <code>SignatureMethod</code> is the algorithm =
>that is used to
>convert the canonicalized <code>SignedInfo</code> into the =
><code>SignatureValue</code>. It
>is a combination of a digest algorithm and a key dependent algorithm and =
>possibly other
>algorithms such as padding, for example RSA-SHA1. The algorithm names =
>are signed to resist
>attacks based on substituting a weaker algorithm. To promote application =
>interoperability
>we specify a set of signature algorithms that MUST be implemented, =
>though their use is at
>the discretion of the signature creator. We specify additional =
>algorithms as RECOMMENDED
>or OPTIONAL for implementation and the signature design permits =
>arbitrary user algorithm
>specification.</p>
>
><p><code>[s05-11]</code> Each <code>Reference</code> element includes =
>the digest method
>and resulting digest value calculated over the identified data object. =
>It also may include
>transformations that produced the input to the digest operation. A data =
>object is signed
>by computing its digest value and a signature over that value. The =
>signature is later
>checked via <a href=3D"#def-ValidationReference" =
>class=3D"link-def">reference</a> and <a
>href=3D"#def-ValidationSignature" class=3D"link-def">signature =
>validation</a>.</p>
>
><p><code>[s14-16]</code> <code>KeyInfo</code> indicates the key to be =
>used to validate the
>signature. Possible forms for identification include certificates, key =
>names, and key
>agreement algorithms and information -- we define only a few. =
><code>KeyInfo</code> is
>optional for two reasons. First, the signer may not wish to reveal key =
>information to all
>document processing parties. Second, the information may be known within =
>the application's
>context and need not be represented explicitly. Since =
><code>KeyInfo</code> is outside of <code>SignedInfo</code>,
>if the signer wishes to bind the keying information to the signature, a =
><code>Reference</code>
>can easily identify and include the <code>KeyInfo</code> as part of the =
>signature.</p>
>
><h3>2.1.1 More on <a id=3D"sec-o-Reference" =
>name=3D"sec-o-Reference"><code>Reference</code></a></h3>
>
><pre class=3D"xml-example">
> [s05] <Reference =
>URI=3D"http://www.w3.org/TR/2000/REC-xhtml1-20000126/">=20
> [s06] <Transforms>=20
> [s07] <Transform =
>Algorithm=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/&g=
>t;=20
> [s08] </Transforms>=20
> [s09] <DigestMethod =
>Algorithm=3D"http://www.w3.org/2000/07/xmldsig#sha1"/>=20
> [s10] =
><DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=3D</DigestValue>=20
> [s11] </Reference>
></pre>
>
><p><code>[s05]</code> The optional <code>URI</code> attribute of =
><code>Reference</code>
>identifies the data object to be signed. This attribute may be omitted =
>on at most one <code>Reference</code>
>in a <code>Signature</code>. (This limitation is imposed in order to =
>ensure that
>references and objects may be matched unambiguously.)</p>
>
><p><code>[s05-08]</code> This identification, along with the transforms, =
>is a description
>provided by the signer on how they obtained the signed data object in =
>the form it was
>digested (i.e. the digested content). The verifier may obtain the =
>digested content in
>another method so long as the digest verifies. In particular, the =
>verifier may obtain the
>content from a different location such as a local store than that =
>specified in the <code>URI</code>.</p>
>
><p><code>[s06-08] Transforms</code> is an optional ordered list of =
>processing steps that
>were applied to the resource's content before it was digested. =
>Transforms can include
>operations such as canonicalization, encoding/decoding (including =
>compression/inflation),
>XSLT and XPath. XPath transforms permit the signer to derive an XML =
>document that omits
>portions of the source document. Consequently those excluded portions =
>can change without
>affecting signature validity. For example, if the resource being signed =
>encloses the
>signature itself, such a transform must be used to exclude the signature =
>value from its
>own computation. If no <code>Transforms</code> element is present, the =
>resource's content
>is digested directly. While we specify mandatory (and optional) =
>canonicalization and
>decoding algorithms, user specified transforms are permitted.</p>
>
><p><code>[s09-10] DigestMethod</code> is the algorithm applied to the =
>data after <code>Transforms</code>
>is applied (if specified) to yield the <code>DigestValue</code>. The =
>signing of the <code>DigestValue</code>
>is what binds a resources content to the signer's key.</p>
>
><h3>2.2 Extended Example (<code>Object</code> and <a =
>id=3D"sec-o-SignatureProperty"
>name=3D"sec-o-SignatureProperty"><code>SignatureProperty</code></a>)</h3>=
>
>
><p>This specification does not address mechanisms for making statements =
>or assertions.
>Instead, this document defines what it means for something to be signed =
>by an XML
>Signature (message authentication, integrity, and/or signer =
>authentication). Applications
>that wish to represent other semantics must rely upon other =
>technologies, such as [<a
>href=3D"#ref-XML">XML</a>, <a href=3D"#ref-RDF">RDF</a>]. For instance, =
>an application might
>use a <code>foo:assuredby</code> attribute within its own markup to =
>reference a <code>Signature</code>
>element. Consequently, it's the application that must understand and =
>know how to make
>trust decisions given the validity of the signature and the meaning of =
><code>assurdby</code>
>syntax. We also define a <code>SignatureProperties</code> element type =
>for the inclusion
>of assertions about the signature itself (e.g., signature semantics, the =
>time of signing
>or the serial number of hardware used in cryptographic processes). Such =
>assertions may be
>signed by including a <code>Reference</code> for the =
><code>SignatureProperties</code> in <code>SignedInfo</code>.
>While the signing application should be very careful about what it signs =
>(it should
>understand what is in the <code>SignatureProperty</code>) a receiving =
>application has no
>obligation to understand that semantic (though its parent trust engine =
>may wish to). Any
>content about the signature generation may be located within the =
>SignatureProperty
>element. The mandatory <code>Target</code> attribute references the =
><code>Signature</code>
>element to which the property applies.</p>
>
><p>Consider the preceding example with an additional reference to a =
>local <code>Object</code>
>that includes a <code>SignatureProperty</code> element. (Such a =
>signature would not only
>be <a href=3D"#def-SignatureDetached" class=3D"link-def">detached</a> =
><code>[p02]</code> but <a
>href=3D"#def-SignatureEnveloping" class=3D"link-def">enveloping</a> =
><code>[p03]</code>.)</p>
>
><pre class=3D"xml-example">
> [ ] ...
> [p01] <SignedInfo> =20
> [ ] ... =20
> [p02] <Reference =
>URI=3D"http://www.w3.org/TR/xml-stylesheet/"> =20
> [ ] ...=20
> [p03] <Reference URI=3D"#AMadeUpTimeStamp" =20
> [p04] =
>Type=3D"http://www.w3.org/2000/07/xmldsig#SignatureProperty">=
>; =20
> [p05] <DigestMethod =
>Algorithm=3D"http://www.w3.org/2000/07/xmldsig#sha1"/> =20
> [p06] =
><DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=3D</DigestValue> =20
> [p07] </Reference> =20
> [p08] </SignedInfo> =20
> [p09] ... =20
> [p10] <Object>=20
> [p11] <SignatureProperties>=20
> [p12] <SignatureProperty Id=3D"AMadeUpTimeStamp" =
>Target=3D"#MySecondSignature">=20
> [p13] <timestamp =
>xmlns=3D"http://www.ietf.org/rfcXXXX.txt"> =20
> [p14] <date>19990908</date> =20
> [p15] <time>14:34:34:34</time> =20
> [p16] </timestamp> =20
> [p17] </SignatureProperty>=20
> [p18] </SignatureProperties>=20
> [p19] </Object> =20
> [p20]</Signature>
></pre>
>
><p><code>[p04]</code> The optional <code>Type</code> attribute of =
><code>Reference</code>
>provides information about the resource identified by the =
><code>URI</code>. In particular,
>it can indicate that it is an <code>Object</code>, =
><code>SignatureProperty</code>, or <code>Manifest</code>
>element. This can be used by applications to initiate special processing =
>of some <code>Reference</code>
>elements. References to an XML data element within an =
><code>Object</code> element SHOULD
>identify the actual element pointed to. Where the element content is not =
>XML (perhaps it
>is binary or encoded data) the reference should identify the =
><code>Object</code> and the <code>Reference</code>
><code>Type</code>, if given, SHOULD indicate <code>Object</code>. Note =
>that <code>Type</code>
>is advisory and no action based on it or checking of its correctness is =
>required by core
>behavior.</p>
>
><p><code>[p10]</code> <code>Object</code> is an optional element for =
>including data
>objects within the signature element or elsewhere. The =
><code>Object</code> can be
>optionally typed and/or encoded.</p>
>
><p><code>[p11-18]</code> Signature properties, such as time of signing, =
>can be optionally
>signed by identifying them from within a <code>Reference</code>. (These =
>properties are
>traditionally called signature "attributes" although that term =
>has no
>relationship to the XML term "attribute".)</p>
>
><h3>2.3 Extended Example (<code>Object</code> and <a =
>id=3D"sec-o-Manifest"
>name=3D"sec-o-Manifest"><code>Manifest</code></a>)</h3>
>
><p>The <code>Manifest</code> element is provided to meet additional =
>requirements not
>directly addressed by the mandatory parts of this specification. Two =
>requirements and the
>way the <code>Manifest</code> satisfies them follows.</p>
>
><p>First, applications frequently need to efficiently sign multiple data =
>objects even
>where the signature operation itself is an expensive public key =
>signature. This
>requirement can be met by including multiple <code>Reference</code> =
>elements within <code>SignedInfo</code>
>since the inclusion of each digest secures the data digested. However, =
>some applications
>may not want the <a href=3D"#def-ValidationCore" class=3D"link-def">core =
>validation</a>
>behavior associated with this approach because it requires every =
><code>Reference</code>
>within <code>SignedInfo</code> to undergo <a =
>href=3D"#def-ValidationReference"
>class=3D"link-def">reference validation</a> -- the =
><code>DigestValue</code> elements are
>checked. These applications may wish to reserve reference validation =
>decision logic to
>themselves. For example, an application might receive a <a =
>href=3D"#def-ValidationSignature"
>class=3D"link-def">signature valid</a> <code>SignedInfo</code> element =
>that includes three <code>Reference</code>
>elements. If a single <code>Reference</code> fails (the identified data =
>object when
>digested does not yield the specified <code>DigestValue</code>) the =
>signature would fail <a
>href=3D"#def-ValidationCore" class=3D"link-def">core validation</a>. =
>However, the application
>may wish to treat the signature over the two valid =
><code>Reference</code> elements as
>valid or take different actions depending on which fails. To =
>accomplish this, <code>SignedInfo</code>
>would reference a <code>Manifest</code> element that contains one or =
>more <code>Reference</code>
>elements (with the same structure as those in <code>SignedInfo</code>). =
>Then, reference
>validation of the <code>Manifest</code> is under application =
>control.</p>
>
><p>Second, consider an application where many signatures (using =
>different keys) are
>applied to a large number of documents. An inefficient solution is to =
>have a separate
>signature (per key) repeatedly applied to a large =
><code>SignedInfo</code> element (with
>many <code>Reference</code>s); this is wasteful and redundant. A more =
>efficient solution
>is to include many references in a single <code>Manifest</code> that is =
>then referenced
>from multiple <code>Signature</code> elements.</p>
>
><p>The example below includes a <code>Reference</code> that signs a =
><code>Manifest</code>
>found within the <code>Object</code> element.</p>
>
><pre class=3D"xml-example">
> [ ] ...
> [m01] <Reference URI=3D"#MyFirstManifest"
> [m02] =
>Type=3D"http://www.w3.org/2000/07/xmldsig#Manifest">
> [m03] <DigestMethod =
>Algorithm=3D"http://www.w3.org/2000/07/xmldsig#sha1"/>=20
> [m04] =
><DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=3D</DigestValue>=20
> [m05] </Reference> =20
> [ ] ...
> [m06] <Object>
> [m07] <Manifest Id=3D"MyFirstManifest">
> [m08] <Reference>
> [m09] ...
> [m10] </Reference> =20
> [m11] <Reference>
> [m12] ...
> [m13] </Reference>
> [m14] </Object>
></pre>
>
><h2>3.0 <a id=3D"sec-Processing" name=3D"sec-Processing">Processing</a> =
>Rules</h2>
>
><p>The sections below describe the operations to be performed as part of =
>signature
>generation and validation.</p>
>
><h3>3.1 Core <a id=3D"sec-CoreGeneration" =
>name=3D"sec-CoreGeneration">Generation</a></h3>
>
><p>The REQUIRED steps include the generation of <code>Reference</code> =
>elements and the <code>SignatureValue</code>
>over <code>SignedInfo</code>.</p>
>
><h4>3.1.1 Reference Generation</h4>
>
><p>For each data object being signed:=20
>
><ol>
> <li>Apply the <code>Transforms</code>, as determined by the =
>application, to the data object.</li>
> <li>Calculate the digest value over the resulting data object.</li>
> <li>Create a <code>Reference</code> element, including the (optional) =
>identification of the
> data object, any (optional) transform elements, the digest algorithm =
>and the <code>DigestValue</code>.</li>
></ol>
>
><h4>3.1.2 Signature Generation</h4>
>
><ol>
> <li>Create <code>SignedInfo</code> element with =
><code>SignatureMethod</code>, <code>CanonicalizationMethod</code>
> and <code>Reference</code>(s).</li>
> <li>Canonicalize and then calculate the <code>SignatureValue</code> =
>over <code>SignedInfo</code>
> based on algorithms specified in <code>SignedInfo</code>.</li>
> <li>Construct the <code>Signature</code> element that includes =
><code>SignedInfo</code>, <code>Object</code>(s)
> (if desired, encoding may be different than that used for signing), =
><code>KeyInfo</code>
> (if required), and <code>SignatureValue</code>.</li>
></ol>
>
><h3>3.2 Core <a id=3D"sec-CoreValidation" =
>name=3D"sec-CoreValidation">Validation</a></h3>
>
><p>The REQUIRED steps of <a href=3D"#def-ValidationCore" =
>class=3D"link-def">core validation</a>
>include (1) <a href=3D"#def-ValidationReference" =
>class=3D"link-def">reference validation</a>,
>the verification of the digest contained in each <code>Reference</code> =
>in <code>SignedInfo</code>,
>and (2) the cryptographic <a href=3D"#def-ValidationSignature" =
>class=3D"link-def">signature
>validation</a> of the signature calculated over =
><code>SignedInfo</code>.</p>
>
><p>Note, there may be valid signatures that some signature applications =
>are unable to
>validate. Reasons for this include failure to implement optional parts =
>of this
>specification, inability or unwillingness to execute specified =
>algorithms, or inability or
>unwillingness to dereference specified URIs (some URI schemes may cause =
>undesirable side
>effects), etc.</p>
>
><h4>3.2.1 Reference Validation</h4>
>
><p>For each <code>Reference</code> in <code>SignedInfo</code>:=20
>
><ol>
> <li><u>Canonicalize the <code>SignedInfo</code> element based on the =
><code>CanonicalizationMethod</code>
> in <code>SignedInfo</code> (so as to ensure the application <a =
>href=3D"#sec-See">Sees What
> is Signed</a>, which is the canonical form).</u></li>
> <li>Obtain the data object to be digested. (The signature application =
>may rely upon the
> identification (<code>URI</code>) and <code>Transforms</code> =
>provided by the signer in
> the <code>Reference</code> element, or it may obtain the content =
>through other means such
> as a local cache.)</li>
> <li>Digest the resulting data object using the =
><code>DigestMethod</code> specified in its <code>Reference</code>
> specification.</li>
> <li>Compare the generated digest value against =
><code>DigestValue</code> in the <code>SignedInfo</code>
> <code>Reference</code>; if there is any mismatch, validation =
>fails.</li>
></ol>
>
><h4>3.2.2 Signature Validation</h4>
>
><ol>
> <li>Canonicalize the <code>SignedInfo</code> element based on the =
><code>CanonicalizationMethod</code>
> in <code>SignedInfo</code>.</li>
> <li>Obtain the keying information from <code>KeyInfo</code> or from an =
>external source.</li>
> <li>Use the specified <code>SignatureMethod</code> to validate the =
><code>SignatureValue</code>
> over the <code>SignedInfo</code> element.</li>
></ol>
>
><h2>4.0 <a id=3D"sec-CoreSyntax" name=3D"sec-CoreSyntax">Core Signature =
>Syntax</a></h2>
>
><p>The general structure of an XML signature is described in section 2: =
><a
>href=3D"#sec-Overview">Signature Overview</a>. This section provides =
>detailed syntax of the
>core signature features and actual examples. Features described in this =
>section are
>mandatory to implement unless otherwise indicated. The syntax is defined =
>via DTDs and [<a
>href=3D"#ref-XML-schema">XML-Schema</a>] with the following XML =
>preamble, declaration,
>internal entity, and simpleType:</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <?xml version=3D'1.0'?>=20
> <!DOCTYPE schema=20
> SYSTEM 'http://www.w3.org/1999/XMLSchema.dtd'=20
> [=20
> <!ENTITY dsig 'http://www.w3.org/2000/07/xmldsig#'>=20
> ]>=20
>
> <schema targetNamespace=3D'&dsig;'=20
> version=3D'0.1'=20
> xmlns=3D'http://www.w3.org/1999/XMLSchema'
> xmlns:ds=3D'&dsig;'
> elementFormDefault=3D'qualified'>=20
>
> <!-- Basic Types Defined for Signatures -->
>
> <simpleType name=3D'CryptoBinary' base=3D'binary'>
> <encoding value=3D'base64'/>
> </simpleType>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!-- These entity declarations permit the flexible parts of =
>Signature
> content model to be easily expanded -->
>
> <!ENTITY % Object.ANY =
>'(#PCDATA|Signature|SignatureProperties|Manifest)*'>
> <!ENTITY % Method.ANY '(#PCDATA|HMACOutputLength)*'>
> <!ENTITY % Transform.ANY '(#PCDATA|XPath|XSLT)*'>
> <!ENTITY % Key.ANY '(#PCDATA|KeyName|KeyValue|RetrievalMethod|=20
> X509Data|PGPData|MgmtData|DSAKeyValue|RSAKeyValue)*'>
></pre>
>
><h3>4.1 The <a id=3D"sec-Signature" =
>name=3D"sec-Signature"><code>Signature</code></a> element</h3>
>
><p>The <code>Signature</code> element is the root element of an XML =
>Signature. <u>Signature
>elements MUST be <a =
>href=3D"http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#cvc-elt-lax">l=
>axly
>schema valid</a> [<a href=3D"#ref-XML-schema">XML-schema</a>]</u> with =
>respect to the
>following schema definition:</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'Signature'>=20
> <complexType content=3D'elementOnly'>
> <sequence minOccurs=3D'1' maxOccurs=3D'1'>=20
> <element ref=3D'ds:SignedInfo' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element ref=3D'ds:SignatureValue' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element ref=3D'ds:KeyInfo' minOccurs=3D'0' =
>maxOccurs=3D'1'/>=20
> <element ref=3D'ds:Object' minOccurs=3D'0' =
>maxOccurs=3D'unbounded'/>=20
> </sequence> =20
> <attribute name=3D'Id' type=3D'ID' use=3D'optional'/>=20
> </complexType>
> </element>=20
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, =
>Object*) >
> <!ATTLIST Signature =20
> xmlns CDATA #FIXED 'http://www.w3.org/2000/07/xmldsig#'
> Id ID #IMPLIED >
></pre>
>
><h3>4.2 The <a id=3D"sec-SignatureValue" =
>name=3D"sec-SignatureValue"><code>SignatureValue</code></a>
>Element</h3>
>
><p>The <code>SignatureValue</code> element contains the actual value of =
>the digital
>signature; it is encoded according to the identifier specified in =
><code>SignatureMethod</code>.
>Base64 [<a href=3D"#ref-MIME">MIME</a>] is the encoding method for all =
><code>SignatureMethod</code>s
>specified within this specification. While we specify a mandatory and =
>optional to
>implement <code>SignatureMethod</code> algorithms, user specified =
>algorithms are
>permitted. <u>Both algorithms specified by this specification and user =
>specified ones MUST
>use Base64 [<a href=3D"#ref-MIME">MIME</a>] as their encoding =
>method.</u><br>
></p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'SignatureValue' type=3D'ds:CryptoBinary'/>=20
></pre>
>
><pre class=3D"xml-dtd"> DTD:
>
> <!ELEMENT SignatureValue (#PCDATA) >
></pre>
>
><h3>4.3 The <a id=3D"sec-SignedInfo" =
>name=3D"sec-SignedInfo"><code>SignedInfo</code></a>
>Element</h3>
>
><p>The structure of <code>SignedInfo</code> includes the =
>canonicalization algorithm, a
>signature algorithm, and one or more references. The =
><code>SignedInfo</code> element may
>contain an optional ID attribute that will allow it to be referenced by =
>other signatures
>and objects.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'SignedInfo'>=20
> <complexType content=3D'elementOnly'>
> <sequence minOccurs=3D'1' maxOccurs=3D'1'>=20
> <element ref=3D'ds:CanonicalizationMethod' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element ref=3D'ds:SignatureMethod' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element ref=3D'ds:Reference' minOccurs=3D'1' =
>maxOccurs=3D'unbounded'/>=20
> </sequence> =20
> <attribute name=3D'Id' type=3D'ID' use=3D'optional'/>=20
> </complexType>
> </element>=20
>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT SignedInfo (CanonicalizationMethod,=20
> SignatureMethod, Reference+) >
> <!ATTLIST SignedInfo =20
> Id ID #IMPLIED>
></pre>
>
><p><code>SignedInfo</code> does not include explicit signature or digest =
>properties (such
>as calculation time, cryptographic device serial number, etc.). If an =
>application needs to
>associate properties with the signature or digest, it may include such =
>information in a <code>SignatureProperties</code>
>element within an <code>Object</code> element.</p>
>
><h4>4.3.1 The <a id=3D"sec-CanonicalizationMethod" =
>name=3D"sec-CanonicalizationMethod"><code>CanonicalizationMethod</code></=
>a>
>Element</h4>
>
><p>CanonicalizationMethod is a required element that specifies the =
>canonicalization
>algorithm applied to the <code>SignedInfo</code> element prior to =
>performing signature
>calculations. This element uses the general structure for algorithms =
>described in section
>6.1: <a href=3D"#sec-AlgID">Algorithm Identifiers and Implementation =
>Requirements</a>.
><u>Implementations MUST support the REQUIRED Canonical XML=20
>[<a href=3D"#ref-XML-C14N">XML-C14N</a>] method</u>.</p>
>
><u john=3D"john">
><p>The Canonical XML implementation should behave as if it received an=20
><a href=3D"#ref-XPath">XPath</a> node-set originally formed from the =
>document=20
>containing the <code>SignedInfo</code> and currently indicating the =
><code>SignedInfo</code>,=20
>its descendants, and the attribute and namespace nodes of =
><code>SignedInfo</code> and its=20
>descendant elements (such that the namespace context and similar =
>ancestor information of=20
>the <code>SignedInfo</code> is preserved). The REQUIRED Canonical XML =
>algorithm omits
>the comments.</u></p>
>
><p>Alternatives <u john=3D"john">to the REQUIRED Canonical XML =
>algorithm</u>, such as=20
><u john=3D"john">Canonical XML with Comments and</u> the minimal =
>canonicalization algorithm=20
>(the CRLF and charset normalization specified in section 6.5.1: <a =
>href=3D"#sec-Minimal">Minimal
>Canonicalization</a>), may be explicitly specified but are NOT REQUIRED. =
>Consequently,
>their use may not interoperate with other applications that do no =
>support the specified
>algorithm (see section 7: <a href=3D"#sec-XML-Canonicalization">XML =
>Canonicalization and
>Syntax Constraint Considerations</a>). Security issues may also arise in =
>the treatment of
>entity processing and comments if minimal or other non-XML aware =
>canonicalization
>algorithms are not properly constrained (see section 8.2: <a =
>href=3D"#sec-Seen">Only What is
>"Seen" Should be Signed</a>).</p>
>
><p>We RECOMMEND that resource constrained applications that do not =
>implement the Canonical
>XML [XML-C14N] <strike john=3D"john">transform</strike> <u =
>john=3D"john">algorithm</u> and=20
>instead choose minimal canonicalization (or some other form) are =
>implemented to generate=20
>Canonical XML as their output serialization to easily mitigate some of =
>these interoperability=20
>and security concerns. For instance, such an implementation SHOULD (at =
>least) generate=20
><a href=3D"http://www.w3.org/TR/REC-xml#sec-rmd">standalone</a> XML =
>instances [<a href=3D"#ref-XML">XML</a>].</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'CanonicalizationMethod'>=20
> <complexType content=3D'elementOnly'>
> <any minOccurs=3D'0' maxOccurs=3D'unbounded'/>
> <attribute name=3D'Algorithm' type=3D'uriReference' =
>use=3D'required'/>=20
> </complexType>
> </element>=20
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT CanonicalizationMethod %Method.ANY; >=20
> <!ATTLIST CanonicalizationMethod=20
> Algorithm CDATA #REQUIRED >=20
></pre>
>
><u john=3D"john">
><p>The algorithm specifier for minimal canonicalization is given in <a =
>href=3D"#sec-Minimal">Section 6.5.1</a>.
>The algorithm specifiers for the REQUIRED Canonical XML algorithm and =
>Canonical XML with
>Comments are given in <a href=3D"#sec-Canonical">Section 6.5.2</a>.</p>
></u>
>
><h4>4.3.2 The <a id=3D"sec-SignatureMethod" =
>name=3D"sec-SignatureMethod"><code>SignatureMethod</code></a>
>Element</h4>
>
><p><code>SignatureMethod</code> is a required element that specifies the =
>algorithm used
>for signature generation and validation. This algorithm identifies all =
>cryptographic
>functions involved in the signature operation (e.g. hashing, public key =
>algorithms, MACs,
>padding, etc.). This element uses the general structure here for =
>algorithms described in
>section 6.1: <a href=3D"#sec-AlgID">Algorithm Identifiers and =
>Implementation Requirements</a>.
>While there is a single identifier, that identifier may specify a format =
>containing
>multiple distinct signature values.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'SignatureMethod'>=20
> <complexType content=3D'elementOnly'>=20
> <any minOccurs=3D'0' maxOccurs=3D'unbounded'/>
> <attribute name=3D'Algorithm' type=3D'uriReference' =
>use=3D'required'/>=20
> </complexType>
> </element>=20
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT SignatureMethod %Method.ANY; >
> <!ATTLIST SignatureMethod=20
> Algorithm CDATA #REQUIRED >=20
></pre>
>
><h4>4.3.3 The <a id=3D"sec-Reference" =
>name=3D"sec-Reference"><code>Reference</code></a>
>Element</h4>
>
><p><code>Reference</code> is an element that may occur one or more =
>times. It specifies a
>digest algorithm and digest value, and optionally an identifier of the =
>object being
>signed, the type of the object, and/or a list of transforms to be =
>applied prior to
>digesting. The identification (URI) and transforms describe how the =
>digested content
>(i.e., the input to the digest method) was created. The =
><code>Type</code> attribute
>facilitates the processing of referenced data. For example, while this =
>specification makes
>no requirements over external data, an application may wish to signal =
>that the referent is
>a <code>Manifest</code>. An optional ID attribute permits a =
><code>Reference</code> to be
>referenced from elsewhere.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'Reference'>=20
> <complexType content=3D'elementOnly'>
> <sequence minOccurs=3D'1' maxOccurs=3D'1'>=20
> <element ref=3D'ds:Transforms' minOccurs=3D'0' =
>maxOccurs=3D'1'/>=20
> <element ref=3D'ds:DigestMethod' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element ref=3D'ds:DigestValue' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> </sequence>
> <attribute name=3D'Id' type=3D'ID' use=3D'optional'/>=20
> <attribute name=3D'URI' type=3D'uriReference' =
>use=3D'optional'/>=20
> <attribute name=3D'Type' type=3D'uriReference' =
>use=3D'optional'/>=20
> </complexType>
> </element>=20
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT Reference (Transforms?, DigestMethod, DigestValue) >
> <!ATTLIST Reference =20
> Id ID #IMPLIED
> URI CDATA #IMPLIED
> Type CDATA #IMPLIED >
></pre>
>
><p>The <code>URI</code> attribute identifies a data object using a =
>URI-Reference, as
>specified by RFC2396 [<a href=3D"#ref-URI">URI</a>]. <u>The set of =
>allowed characters for <code>URI</code>
>attributes is the same as for XML, namely <a =
>href=3D"#ref-Unicode">[Unicode]</a>. However,
>some Unicode characters are disallowed from URI references including all =
>non-ASCII
>characters and the excluded characters listed in Section 2.4 of RFC2396 =
>[<a
>href=3D"#ref-URI">URI</a>]. However, the number sign (#), percent sign =
>(%), and square
>bracket characters re-allowed in RFC 2732 [<a =
>href=3D"#ref-URI-Literal">URI-Literal</a>] are
>permitted. Disallowed characters must be escaped as follows:</u>=20
>
><ol>
> <li><u>Each disallowed character is converted to [<a =
>href=3D"#ref-UTF-8">UTF-8</a>] as one or
> more bytes. </u></li>
> <li><u>Any octets corresponding to a disallowed character are escaped =
>with the URI escaping
> mechanism (that is, converted to %HH, where HH is the hexadecimal =
>notation of the byte
> value). </u></li>
> <li><u>The original character is replaced by the resulting character =
>sequence. </u></li>
></ol>
>
><p><strike john=3D"john">
>Note that a null URI (<code>URI=3D""</code>) is permitted and =
>identifies the
>XML document that the reference is contained within (the root =
><u>node</u>).
></strike>=20
>
><u john=3D"john">
><!-- Moved from below, but wording not changed -->
><p>If a resource is identified by more than one URI, the most specific =
>should be used (e.g. <a
>href=3D"http://www.w3.org/2000/06/interop-pressrelease.html.en">http://ww=
>w.w3.org/2000/06/interop-pressrelease.html.en</a>
>instead of <a =
>href=3D"http://www.w3.org/2000/06/interop-pressrelease">http://www.w3.org=
>/2000/06/interop-pressrelease</a>).</p>
></u>
>
>XML Signature applications MUST be able to parse URI syntax. We =
>RECOMMEND they be able to=20
>dereference URIs <strike john=3D"john">and null URIs</strike> in the =
>HTTP scheme.=20
>(See the <a href=3D"#sec-CoreValidation">section
>3.2.1:Reference Validation</a> for a further comment on URI =
>dereferencing.)
>
><p><u john=3D"john">Unless the URI-Reference is a 'same-document' =
>reference as defined in=20
>[<a href=3D"#ref-URI">URI</a>, Section 4.2], the result of dereferencing =
>the URI-Reference MUST be an=20
>octet stream. In particular, an XML document identified by URI is not =
>parsed by the
>signature application unless the URI is a same-document reference or =
>unless a Transform that=20
>requires XML parsing is applied (See <a href=3D"#sec-Transforms">Section =
>4.3.3.1</a>). </u>=20
>
>Applications should <u john=3D"john">also</u> be cognizant of the fact =
>that protocol parameter and=20
>state information, (such as a HTTP cookies, HTML device profiles or =
>content negotiation),=20
>may affect the content yielded by dereferencing a URI.=20
>
><u john=3D"john">This is particularly true if the URI dereference =
>includes fragment processing
>of an XML document.</u>=20
>
><strike john=3D"john"> <!-- moved this to above -->
><u> If a resource is identified by more than one URI, the most specific =
>should be used (e.g. <a
>href=3D"http://www.w3.org/2000/06/interop-pressrelease.html.en">http://ww=
>w.w3.org/2000/06/interop-pressrelease.html.en</a>
>instead of <a =
>href=3D"http://www.w3.org/2000/06/interop-pressrelease">http://www.w3.org=
>/2000/06/interop-pressrelease</a>).</u></p>
></strike>
>
><u john=3D"john">
><p>If the <code>URI</code> is a same-document reference, then the =
>signature
>application MUST behave as if the URI dereference has resulted in an =
>XPath node-set suitable
>for use by Canonical XML. Specifically, a null URI =
>(<code>URI=3D""</code>) MUST behave
>as if it resulted in an XPath node-set that includes every non-comment =
>node of the XML document
>containing the <code>URI</code> attribute. In a fragment URI, the =
>characters=20
>after the crosshatch ('#') character conform to the XPointer syntax [<a =
>href=3D"#ref-XPointer">Xptr</a>].=20
>When processing an XPointer, the application MUST behave as if the root =
>node of the XML document=20
>containing the <code>URI</code> attribute were used to initialize the =
>XPointer evaluation context. =20
>The application MUST behave as if the result of XPointer processing were =
>a node-set derived from=20
>the resultant location-set as follows:</p>
>
><ol>
><li>discard point nodes</li>
><li>replace each range node with all XPath nodes having full or partial =
>content within the range</li>
><li>replace any element node <b>E</b> with <b>E</b> plus all descendants =
>of <b>E</b> (text,
> comment, PI, element) and all namespace and attribute nodes of <b>E</b>
> =
>and its=20
> descendant elements.</li>
><li>if the URI is not a full XPointer, then delete all comment =
>nodes</li>
></ol>
>
><p>The third replacement is necessary because XPointer typically =
>indicates a subtree of
>an XML document's parse tree using just the element node at the root of =
>the subtree, whereas
>Canonical XML treats a node-set as a set of nodes in which absence of =
>descendant nodes results in
>absence of their representative text from the canonical form.</p>
>
><p>The fourth step is performed for null URIs, barename XPointers and =
>child sequence XPointers.
>To retain comments while selecting an element by an identifier =
><i>ID</i>, use the following full
>XPointer: <code>URI=3D'#xpointer(id("<i>ID</i>"))'</code>. To retain =
>comments while selecting
>the entire document, use the following full XPointer:=20
><code>URI=3D'#xpointer(//. | //@* | //namespace::*)'</code>. This =
>XPointer contains a simple XPath
>expression that includes all nodes of the parse tree (the root and all =
>descendants, plus all=20
>attributes, plus all namespaces nodes).</p>
>
><p>When a fragment is preceded by an absolute or relative URI in the =
>URI-Reference,
>the meaning of the fragment is defined by the resource's MIME type. =
>Even for XML documents,=20
>URI dereference (including the fragment processing) may be done for the =
>signature application by=20
>a proxy user agent. Therefore, reference validation may fail if =
>fragment processing is not
>performed in a standard way (as defined above for same-document =
>references). To prevent this=20
>interoperability problem when signing XML document fragments, we =
>RECOMMEND using only the document=20
>URI and performing the fragment processing using an <a =
>href=3D"#sec-XPath">XPath Transform</a>.</p>
>
><p>XML Signature applications MUST support the null URI and barename =
>XPointers. =20
>We RECOMMEND support for the same-document XPointers '#xpointer(//. | =
>//@* | //namespace::*)' and=20
>'#xpointer(id("<i>ID</i>"))' if the application also intends to support=20
><a href=3D"#sec-Minimal">Minimal Canonicalization</a> or=20
><a href=3D"#sec-Canonical">Canonical XML with Comments</a>. =20
>All other support for XPointers is OPTIONAL, especially all support for =
>barename and other XPointers
>in external resources since the application may not have control over =
>how the fragment is generated
>(leading to the aforementioned interoperability problems and validation =
>failures).=20
>Some examples of URI attributes are</p>
>
><dl>
> <dt><code>URI=3D"http://example.com/bar.xml"</code></dt>
> <dd>Identifies the (unparsed) external XML resource =
>'http://example.com/bar.xml'.</dd>
> =
><dt><code>URI=3D"http://example.com/bar.xml#chapter1"</code></d=
>t>
> <dd>Identifies the element with ID attribute value 'chapter1' of the =
>external XML resource
> 'http://example.com/bar.xml', <u john=3D"john">provided as an octet =
>stream. =20
> Again, for the sake of interoperability, the element identified as =
>'chapter1' should be=20
> obtained using an XPath Transform rather than a URI fragment =
>(barename XPointer
> resolution in external resources is not REQUIRED in this =
>specification).</u></dd>
> <dt><code>URI=3D""</code></dt>
> <dd>Identifies the XML resource containing the signature.</dd>
> <dt><code>URI=3D"#chapter1"</code></dt>
> <dd>Identifies the element with ID attribute value 'chapter1' of the =
>XML resource containing
> the signature.</dd>
></dl>
>
></u>
>
><strike john=3D"john">
>
><p>[<a href=3D"#ref-URI">URI</a>] permits identifiers that specify a =
>fragment identifier via
>a separating number/pound symbol '#'. (The meaning of the fragment is =
>defined by the
>resource's MIME type). XML Signature applications MUST support the =
>XPointer '<a
>href=3D"http://www.w3.org/TR/xptr#bare-names">bare name</a>' [<a =
>href=3D"#ref-XPointer">Xptr</a>]
>shortcut after '#' so as to identify IDs within XML documents. The =
>results are serialized
>as specified in <a href=3D"#sec-XPath">section 6.6.3:XPath =
>Filtering</a>. For example,=20
>
><dl>
> <dt><code>URI=3D"http://example.com/bar.xml"</code></dt>
> <dd>Identifies the external XML resource =
>'http://example.com/bar.xml'.</dd>
> =
><dt><code>URI=3D"http://example.com/bar.xml#chapter1"</code></d=
>t>
> <dd>Identifies the element with ID attribute value 'chapter1' of the =
>external XML resource
> 'http://example.com/bar.xml'.</dd>
> <dt><code>URI=3D""</code></dt>
> <dd>Identifies the XML resource containing the signature.<strike =
>john=3D"john">.</strike></dd>
> <dt><code>URI=3D"#chapter1"</code></dt>
> <dd>Identifies the element with ID attribute value 'chapter1' of the =
>XML resource containing
> the signature.</dd>
></dl>
>
><p>Otherwise, support of other fragment/MIME types (e.g., PDF) or XML =
>addressing
>mechanisms (e.g., [<a href=3D"#ref-XPath">XPath</a>, <a =
>href=3D"#ref-XPointer">Xptr</a>]) is
>OPTIONAL, though we RECOMMEND support of [<a =
>href=3D"#ref-XPath">XPath</a>]. Regardless,
>such fragment identification and addressing SHOULD be given under =
><code>Transforms</code>
>(not as part of the URI) so that they can be fully identified and =
>specified. For instance,
>one could reference a fragment of a document that is encoded by using =
>the <code>Reference</code>
><code>URI</code> to identify the resource, and one =
><code>Transform</code> to specify
>decoding, and a second to specify an XPath selection.</p>
>
></strike>
>
><p>If the <code>URI</code> attribute is omitted altogether, the =
>receiving application is
expected to know the identity of the object. For example, a lightweight =
>data protocol
>might omit this attribute given the identity of the object is part of =
>the application
>context. This attribute may be omitted from at most one =
><code>Reference</code> in any
>particular <code>SignedInfo</code>, or <code>Manifest</code>.</p>
>
><p><u john=3D"john">The result of resolving the URI is passed to the =
>Transforms, if any,=20
>for further processing. The result of the Transforms, or of the URI =
>dereference if
>there are no transforms, is either an octet stream or an XPath node-set =
>(or a sufficiently
>functional replacement). If the result is not an octet stream, the =
>node-set is converted=20
>to an octet stream using the REQUIRED Canonical XML algorithm (which =
>omits comments).=20
>The resulting octet stream contains the data octets being secured. The =
>digest algorithm specified by=20
><code>DigestMethod</code> is then applied to these data octets, =
>resulting in the <code>DigestValue</code>.</u></p>
>
><strike john=3D"john">
><p>The digest algorithm is then applied to the data octets being =
>secured. Typically that is
>done by locating (possibly using the <code>URI</code> if provided) the =
>data and
>transforming it. If the data is an XML document, the document is assumed =
>to be unparsed
>prior to the application of <code>Transforms</code>. If there are no =
><code>Transforms</code>,
>then the data is passed to the digest algorithm unmodified.</p>
></strike>
>
><p>The optional Type attribute contains information about the type of =
>object being signed.
>This is represented as a URI. For example:</p>
>
><p><code>Type=3D<a =
>href=3D"http://www.w3.org/2000/07/xmldsig#Object">"http://www.w3.org=
>/2000/07/xmldsig#Object"</a><br
>/>
>Type=3D<a =
>href=3D"http://www.w3.org/2000/07/xmldsig#Manifest">"http://www.w3.o=
>rg/2000/07/xmldsig#Manifest"</a><br
>/>
>Type=3D"<a =
>href=3D"http://www.w3.org/2000/07/xmldsig#SignatureProperty">http://www.w=
>3.org/2000/07/xmldsig#SignatureProperty</a>"</code></p>
>
><p>The Type attribute applies to the item being pointed at, not its =
>contents. For example,
>a reference that identifies an Object element containing a =
>S<code>ignatureProperties</code>
>element is still of type <code>#Object</code>. The type attribute is =
>advisory. No
>validation of the type information is required by this =
>specification.</p>
>
><h4>4.3.3.1 The <a id=3D"sec-Transforms" =
>name=3D"sec-Transforms"><code>Transforms</code></a>
>Element</h4>
>
><p>The optional <code>Transforms</code> element contains an ordered list =
>of <code>Transform</code>
>elements; these describe how the signer obtained the data object that =
>was digested. The
>output of each <code>Transform</code> <strike =
>john=3D"john">(octets)</strike> serves as input to the=20
>next <code>Transform</code>.
>The input to the first <code>Transform</code> is the <strike =
>john=3D"john">source data</strike>=20
><u john=3D"john">result of dereferencing the URI attribute of the =
><code>Reference</code> element</u>.=20
>The output from the last <code>Transform</code> is the input for the =
><code>DigestMethod</code> algorithm.=20
>When transforms are applied the signer is not signing the native =
>(original) document but the
>resulting (transformed) document, (see section 8.1: <a =
>href=3D"#sec-Secure">Only What is
>Signed is Secure</a>).</p>
>
><p>Each <code>Transform</code> consists of an <code>Algorithm</code> =
>attribute and content
>parameters, if any, appropriate for the given algorithm. The =
><code>Algorithm</code>
>attribute value specifies the name of the algorithm to be performed, and =
>the <code>Transform</code>
>content provides additional data to govern the algorithm's processing of =
>the=20
><u john=3D"john">transform</u> input <strike =
>john=3D"john">resource</strike>,=20
>(see section 6.1: <a href=3D"#sec-AlgID">Algorithm Identifiers and =
>Implementation Requirements</a>).</p>
>
><u john=3D"john">
><p>Some transforms take an XPath node-set (or sufficiently functional =
>alternative) as input,=20
>while others require an octet stream. If the actual input matches the =
input needs of the transform, then the transform operates on=20
>the unaltered input. If the transform input requirement differs from =
>the format of the actual=20
>input, then the input must be converted. Each transform defines how =
>this conversion is performed.</p>
></u>
>
><p>Some <code>Transform</code> may require explicit MimeType, Charset =
>(IANA registered
>"character set"), or other such information concerning the =
>data they are
>receiving from an earlier <code>Transform</code> or the source data, =
>although no <code>Transform</code>
>algorithm specified in this document needs such <u>explicit</u> =
>information. Such data
>characteristics are provided as parameters to the <code>Transform</code> =
>algorithm and
>should be described in the specification for the algorithm.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
> <element name=3D'Transforms' >=20
> <complexType content=3D'elementOnly'>=20
> <element ref=3D'ds:Transform' minOccurs=3D'1' =
>maxOccurs=3D'unbounded'/> =20
> </complexType>
> </element>=20
>
> <element name=3D'Transform'>=20
> <complexType content=3D'mixed'>
> <choice minOccurs=3D'1' maxOccurs=3D'unbounded'>=20
> <any namespace=3D'##other' <u>processContents=3D'lax'</u> =
>minOccurs=3D'0' maxOccurs=3D'unbounded'/>
> <strike john=3D"john"><u><!-- Including well formed XSLT =
>elements --></u></strike>
> <u john=3D"john"><element name=3D'XSLT' type=3D'string'/> =
><!-- Must be well formed XSL stylesheet or transform element =
>--></u>
> <element name=3D'X<u>P</u>ath' type=3D'string'/>=20
> </choice>
> <attribute name=3D'Algorithm' type=3D'uriReference' =
>use=3D'required'/>=20
> </complexType>
> </element>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT Transforms (Transform+)>
>
> <!ELEMENT Transform %Transform.ANY; >
> <!ATTLIST Transform=20
> Algorithm CDATA #REQUIRED >
>
> <!ELEMENT XPath (#PCDATA) >
> <!ELEMENT XSLT (#PCDATA) >
></pre>
>
><p>Examples of transforms include but are not limited to base64 decoding =
>[<a
>href=3D"#ref-MIME">MIME</a>], canonicalization [<a =
>href=3D"#ref-XML-C14N">XML-C14N</a>], XPath
>filtering [<a href=3D"#ref-XPath">XPath</a>], and XSLT [<a =
>href=3D"#ref-XSLT">XSLT</a>]. The
>generic definition of the <code>Transform</code> element also allows =
>application-specific
>transform algorithms. For example, the transform could be a =
>decompression routine given by
>a Java class appearing as a base64 encoded parameter to a Java =
><code>Transform</code>
>algorithm. However, applications should refrain from using =
>application-specific transforms
>if they wish their signatures to be verifiable outside of their =
>application domain.
>Section 6.6: <a href=3D"#sec-Transforms">Transform Algorithms</a> =
>defines the list of
>standard transformations.</p>
>
><h4>4.3.3.2 The <a id=3D"sec-DigestMethod" =
>name=3D"sec-DigestMethod"><code>DigestMethod</code></a>
>Element</h4>
>
><p>DigestMethod is a required element that identifies the digest =
>algorithm to be applied
>to the signed object. This element uses the general structure here for =
>algorithms
>specified in section 6.1: <a href=3D"#sec-AlgID">Algorithm Identifiers =
>and Implementation
>Requirements</a>.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'DigestMethod'>=20
> <complexType content=3D'elementOnly'>=20
> <any <u>processContents=3D'lax'</u> minOccurs=3D'0' =
>maxOccurs=3D'unbounded'/>
> <attribute name=3D'Algorithm' type=3D'uriReference' =
>use=3D'required'/>=20
> </complexType>
> </element>=20
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT DigestMethod %Method.ANY; >
> <!ATTLIST DigestMethod =20
> Algorithm CDATA #REQUIRED >
></pre>
>
><u john=3D"john">
><p>If the result of the URI dereference and application of Transforms is =
>an XPath
>node-set (or sufficiently functional replacement implemented by the =
>application),=20
>then the application MUST convert the node-set to an octet stream using
>the REQUIRED Canonical XML algorithm (or perform a logically equivalent =
>operation,
>omitting comments). If the result of URI dereference and application of =
>Transforms
>is an octet stream, then no conversion occurs (comments may be included =
>if the=20
>Minimal Canonicalization or Canonical XML with Comments was specified in =
>the=20
>Transforms). The digest algorithm is applied to the data octets of the=20
>resulting octet stream.</p>
></u>
>
><h4>4.3.3.3 The <a id=3D"sec-DigestValue" =
>name=3D"sec-DigestValue"><code>DigestValue</code></a>
>Element</h4>
>
><p>DigestValue is an element that contains the encoded value of the =
>digest. The digest is
>always encoded using base64 [<a href=3D"#ref-MIME">MIME</a>].</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'DigestValue' type=3D'ds:CryptoBinary'/>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT DigestValue (#PCDATA) >
> <code><!-- base64 encoded <u>digest</u> value --></code>
></pre>
>
><h3>4.4 The <a id=3D"sec-KeyInfo" =
>name=3D"sec-KeyInfo"><code>KeyInfo</code></a> Element</h3>
>
><p><code>KeyInfo</code> may contain keys, names, certificates and other =
>public key
>management information, such as in-band key distribution or key =
>agreement data. This
>specification defines a few simple types but applications may place =
>their own key
>identification and exchange semantics within this element type through =
>the XML-namespace
>facility. [<a href=3D"#ref-XML-ns">XML-ns</a>]</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'KeyInfo'>=20
> <complexType content=3D'elementOnly'>
> <choice minOccurs=3D'1' maxOccurs=3D'unbounded'>
> <any namespace=3D'##other' <u>processContents=3D'lax'</u> =
>minOccurs=3D'<u>0</u>'=20
> maxOccurs=3D'unbounded'/> =20
> <element name=3D'KeyName' type=3D'string'/>=20
> <element ref=3D'ds:KeyValue'/>=20
> <element ref=3D'ds:RetrievalMethod'/>=20
> <element ref=3D'ds:X509Data'/>=20
> <element ref=3D'ds:PGPData'/>=20
> <element ref=3D'ds:SPKIData'/>
> <element name=3D'MgmtData' type=3D'string' />
> </choice>
> <attribute name=3D'Id' type=3D'ID' use=3D'optional'/>=20
> </complexType>
> </element>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT KeyInfo %Key.ANY; >
> <!ATTLIST KeyInfo =20
> Id ID #IMPLIED >
></pre>
>
><p><code>KeyInfo</code> is an optional element that enables the =
>recipient(s) to obtain the
>key needed to validate the signature. If omitted, the recipient is =
>expected to be able to
>identify the key based on application context information. Multiple =
>declarations within <code>KeyInfo</code>
>refer to the same key. While applications may define and use any =
>mechanism they choose
>through inclusion of elements from a different namespace, compliant =
>versions MUST
>implement Section 4.4.2: <a =
>href=3D"#sec-KeyValue"><code>KeyValue</code></a> and SHOULD
>implement Section 4.4.3: <a =
>href=3D"#sec-RetrievalMethod"><code>RetrievalMethod</code></a>.</p>
>
><h3>4.4.1 The <a id=3D"sec-KeyName" =
>name=3D"sec-KeyName"><code>KeyName</code></a> Element</h3>
>
><p>The <code>KeyName</code> element contains a string value which may be =
>used by the
>signer to communicate a key identifier to the recipient. Typically, =
><code>KeyName</code>
>contains an identifier related to the key pair used to sign the message, =
>but it may
>contain other protocol-related information that indirectly identifies a =
>key pair. (Common
>uses of <code>KeyName</code> include simple string names for keys, a key =
>index, a
>distinguished name (DN), an email address, etc.)</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <!-- type declared in KeyInfo -->
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT KeyName (#PCDATA) >
></pre>
>
><h3>4.4.2 The <a id=3D"sec-KeyValue" =
>name=3D"sec-KeyValue"><code>KeyValue</code></a> Element</h3>
>
><p>The <code>KeyValue</code> element contains <u>a single</u> public key =
>that may be
>useful in validating the signature. Structured formats for defining DSA =
>(REQUIRED) and RSA
>(RECOMMENDED) public keys are defined in Section 6.4: <a =
>href=3D"#sec-SignatureAlg">Signature
>Algorithms</a>.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'KeyValue'>
> <complexType content=3D'mixed'>
> <choice minOccurs=3D'1' maxOccurs=3D'1'>
> <any namespace=3D'##other' <u>processContents=3D'lax'</u> =
>minOccurs=3D'0' maxOccurs=3D'unbounded'/>
> <element ref=3D'ds:DSAKeyValue'/>
> <element ref=3D'ds:RSAKeyValue'/>
> </choice>
> </complexType >
> </element>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT KeyValue %Key.ANY; >
></pre>
>
><h3>4.4.3 The <a id=3D"sec-RetrievalMethod" =
>name=3D"sec-RetrievalMethod"><code>RetrievalMethod</code></a>
>Element</h3>
>
><p>A <code>RetrievalMethod</code> element within <code>KeyInfo</code> is =
>used to convey a
>pointer to <code>KeyInfo</code>-like information that is stored at a =
>remote location. For
>example, an X.509v3 certificate chain may be published somewhere common =
>to a number of
>documents; each document can reference this chain using a single =
><code>RetrievalMethod</code>
>element instead of including the entire chain with a sequence of =
>X509Certificate elements.</p>
>
><p>Each <code>RetrievalMethod</code> element contains three children =
>elements: <code>Location</code>,
><code>Method</code> and <code>Type</code>. <code>Location</code> =
>contains a URI
>identifying the actual object. <code>Method</code> describes the process =
>by which the data
>retrieved from the <code>Location</code> URI should be converted into =
><code>KeyInfo</code>
>sub-elements. The <code>Type</code> sub-element describes the object =
>type and encoding
>format of the data stored at the <code>Location</code> URI.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'RetrievalMethod'>=20
> <complexType content=3D'elementOnly'>
> <sequence minOccurs=3D'1' maxOccurs=3D'1'>=20
> <element name=3D'Location' type=3D'uriReference' =
>minOccurs=3D'1' maxOccurs=3D'1'/>=20
> <element name=3D'Method' type=3D'string' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element ref=3D'ds:Type' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> </sequence>
> </complexType>
> </element>=20
>
> <element name=3D'Type'>
> <complexType content=3D'mixed'>
> <any namespace=3D'##other' minOccurs=3D'1' =
>maxOccurs=3D'unbounded'/>
> <attribute name=3D'Encoding' type=3D'uriReference' =
>use=3D'optional'/>
> </complexType>
> </element>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT RetrievalMethod (Location, Method, Type) >
> <!ELEMENT Location %Key.ANY; >
> <!ELEMENT Method %Key.ANY; >
> <!ELEMENT Type %Key.ANY; >
> <!ATTLIST Type=20
> Encoding CDATA #IMPLIED>
></pre>
>
><h3>4.4.4 The <a id=3D"sec-X509Data" =
>name=3D"sec-X509Data"><code>X509Data</code></a> Element</h3>
>
><p><code>An X509Data</code> element within <code>KeyInfo</code> contains =
>one or more
>identifiers of keys/X509 certificates that may be useful for validation. =
>Five types of <code>X509Data</code>
>pointers are defined:=20
>
><ol>
> <li>The <code>X509IssuerSerial</code> element, which contains an X.509 =
>issuer distinguished
> name/serial number pair that SHOULD be compliant with <u>RFC2253 [<a =
>href=3D"#ref-LDAP-DN">LDAP-DN</a>]</u>,
> </li>
> <li>The <code>X509SubjectName</code> element, which contains an X.509 =
>subject distinguished
> name that SHOULD be compliant with <u>RFC2253 [<a =
>href=3D"#ref-LDAP-DN">LDAP-DN</a>]</u>, </li>
> <li>The <code>X509SKI</code> element, which contains an X.509 subject =
>key identifier value. </li>
> <li>The <code>X509Certificate</code> element, which contains a =
>Base64-encoded X.509v3
> certificate, and </li>
> <li>The <code>X509CRL</code> element, which contains a Base64-encoded =
>X.509v2 certificate
> revocation list (CRL). </li>
></ol>
>
><p>Multiple declarations about a single certificate (e.g., a =
><code>X509SubjectName</code>
>and <code>X509IssuerSerial</code> element) MUST be grouped inside a =
>single <code>X509Data</code>
>element; multiple declarations about the same key but different =
>certificates (related to
>that single key) MUST be grouped within a single <code>KeyInfo</code> =
>element but multiple
><code>X509Data</code> elements. For example, the following block =
>contains two pointers to
>certificate-A (issuer/serial number and SKI) and a single reference to =
>certificate-B
>(SubjectName):</p>
>
><pre class=3D"xml-example"> <X509Data> <!-- two pointers to =
>certificate-A -->
> <X509IssuerSerial>=20
> <X509IssuerName><span
>class=3D"tx">CN=3DTAMURA Kent, OU=3DTRL, O=3DIBM,=20
> L=3DYamato-shi, ST=3DKanagawa, =
>C=3DJP</span></X509IssuerName>
> <X509SerialNumber>12345678</X509SerialNumber>
> </X509IssuerSerial>
> <X509SKI>31d97bd7</X509SKI>=20
> </X509Data>
> <X509Data> <!-- single pointer to certificate-B -->
> <X509SubjectName>Subject of <u>Certificate =
>B</u></X509SubjectName>
> </X509Data></pre>
>
><pre class=3D"xml-dtd"> Schema Definition:
>
> <element name=3D'X509Data'>=20
> <complexType content=3D'elementOnly'>=20
> <choice minOccurs=3D'1' maxOccurs=3D'<u>1</u>'>
> <sequence minOccurs=3D'1' maxOccurs=3D'<u>unbounded</u>'> =
>
> <choice minOccurs=3D'1' maxOccurs=3D'1'>=20
> <element ref=3D'ds:X509IssuerSerial'/>
> <element name=3D'X509SKI' type=3D'ds:CryptoBinary'/>
> <element name=3D'X509SubjectName' type=3D'string'/>=20
> </choice> =20
> </sequence>
> <element name=3D'X509Certificate' type=3D'ds:CryptoBinary' =
>minOccurs=3D'<u>1</u>' maxOccurs=3D'<u>1</u>'/>=20
> <element name=3D'X509CRL' type=3D'<u>ds:CryptoBinary</u>' =
>minOccurs=3D'<u>1</u>' maxOccurs=3D'<u>1</u>'/>=20
> </choice>
> </complexType>
> </element>
>
> <element name=3D'X509IssuerSerial'>=20
> <complexType content=3D'elementOnly'>=20
> <sequence minOccurs=3D'1' maxOccurs=3D'1'>=20
> <element name=3D'X509IssuerName' type=3D'string' =
>minOccurs=3D'1' maxOccurs=3D'1'/>=20
> <element name=3D'X509SerialNumber' type=3D'<u>integer</u>' =
>minOccurs=3D'1' maxOccurs=3D'1'/>=20
> </sequence>
> </complexType>
> </element>
></pre>
>
><pre class=3D"xml-dtd"> DTD:
>
> <u> <!ELEMENT X509Data ((X509IssuerSerial | X509SKI | =
>X509SubjectName)+ |
> X509Certificate | X509CRL)></u>
> <!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
> <!ELEMENT X509IssuerName (#PCDATA) >
> <!ELEMENT X509SubjectName (#PCDATA) >
> <!ELEMENT X509SerialNumber (#PCDATA) >
> <!ELEMENT X509SKI (#PCDATA) >
> <!ELEMENT X509Certificate (#PCDATA) >
> <!ELEMENT X509CRL (#PCDATA) ></pre>
>
><h3>4.4.5 The <a id=3D"sec-PGPData" =
>name=3D"sec-PGPData"><code>PGPData</code></a> element</h3>
>
><p>The <code>PGPData</code> element within <code>KeyInfo</code> is used =
>to convey
>information related to PGP public key pairs and signatures on such keys. =
>The <code>PGPKeyID</code>'s
>value is a string containing a standard PGP public key identifier as =
>defined in Section
>11.2 of [<a href=3D"#ref-PGP">PGP</a>]. The <code>PGPKeyPacket</code> =
>contains a
>base64-encoded Key Material Packet as defined in Section 5.5 of [<a =
>href=3D"#ref-PGP">PGP</a>].
>Other sub-types of the <code>PGPData</code> element may be defined by =
>the OpenPGP working
>group.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'PGPData'>=20
> <complexType content=3D'elementOnly'>=20
> <u><choice minOccurs=3D'1' maxOccurs=3D'1'></u>
> <any namespace=3D'##other' <u>processContents=3D'lax'</u> =
>minOccurs=3D'<u>0</u>' maxOccurs=3D'unbounded'/>
> <sequence minOccurs=3D'1' maxOccurs=3D'1'>
> <element name=3D'PGPKeyID' type=3D'string' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element name=3D'PGPKeyPacket' type=3D'ds:CryptoBinary' =
>minOccurs=3D'1' maxOccurs=3D'1'/>=20
> </sequence> =20
> <u></choice></u>
> </complexType>
> </element></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT <u>PGPData</u> (PGPKeyID, PGPKeyPacket) >
> <!ELEMENT PGPKeyPacket (#PCDATA) >
> <!ELEMENT PGPKeyID (#PCDATA) >
></pre>
>
><h3>4.4.6 The <a id=3D"sec-SPKIData" =
>name=3D"sec-SPKIData"><code>SPKIData</code></a> element</h3>
>
><p>The <code>SPKIData</code> element within <code>KeyInfo</code> is used =
>to convey
>information related to SPKI public key pairs, certificates and other =
>SPKI data. The
>content of this element type is open and can be defined elsewhere.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'SPKIData'>=20
> <complexType content=3D'elementOnly'>=20
> <any namespace=3D'##other' <u>processContents=3D'lax'</u> =
>minOccurs=3D'1' maxOccurs=3D'unbounded'/>
> </complexType>
> </element>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT SPKIData (#PCDATA) >
></pre>
>
><h3>4.4.6 The <a id=3D"sec-MgmtData" =
>name=3D"sec-MgmtData"><code>MgmtData</code></a> element</h3>
>
><p>The <code>MgmtData</code> element within <code>KeyInfo</code> is a =
>string value used to
>convey in-band key distribution or agreement data. For example, DH key =
>exchange, RSA key
>encryption, etc.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <!-- type declared in KeyInfo -->
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT MgmtData (#PCDATA)>
></pre>
>
><h3>4.5 The <a id=3D"sec-Object" =
>name=3D"sec-Object"><code>Object</code></a> Element</h3>
>
><dl>
> <dt>Identifier</dt>
> <dd><code>Type=3D<a id=3D"Object" =
>href=3D"http://www.w3.org/2000/07/xmldsig#Object" =
>name=3D"Object">"http://www.w3.org/2000/07/xmldsig#Object"</a><=
>br
> />
> </code>(this can be used within a <code>Reference</code> element to =
>identify the
> referent's type)</dd>
></dl>
>
><p><code>Object</code> is an optional element that may occur one or more =
>times. When
>present, this element may contain any data. The <code>Object</code> =
>element may include
>optional MIME type, ID, and encoding attributes.</p>
>
><p>The <code>MimeType</code> attribute is an optional attribute which =
>describes the data
>within the <code>Object</code>. This is a string with values defined by =
>[<a
>href=3D"#ref-MIME">MIME</a>]. For example, if the <code>Object</code> =
>contains XML, the <code>MimeType</code>
>could be text/xml. This attribute is purely advisory; no validation of =
>the <code>MimeType</code>
>information is required by this specification.</p>
>
><p>The <code>Object</code>'s <code>Id</code> is commonly referenced from =
>a <code>Reference</code>
>in <code>SignedInfo</code>, or <code>Manifest</code>. This element is =
>typically used for <a
>href=3D"#def-SignatureEnveloping" class=3D"link-def">enveloping =
>signatures</a> where the
>object being signed is to be included in the signature element. The =
>digest is calculated
>over the entire <code>Object</code> element including start and end =
>tags.</p>
>
><p><u>The <code>Object</code>'s <code>Encoding</code> attributed may be =
>used to provide a
>URI that identifies the method by which the object is encoded (e.g., a =
>binary file).</u></p>
>
><p>Note, if the application wishes to exclude the =
><code><Object></code> tags from
>the digest calculation the <code>Reference</code> must identify the =
>actual data object
>(easy for XML documents) or a transform must be used to remove the =
><code>Object</code>
>tags (likely where the data object is non-XML). Exclusion of the object =
>tags may be
>desired for cases where one wants the signature to remain valid if the =
>data object is
>moved from inside a signature to outside the signature (or vice-versa), =
>or where the
>content of the <code>Object</code> is an encoding of an original binary =
>document and it is
>desired to extract and decode so as to sign the original bitwise =
>representation.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'Object' >=20
> <complexType content=3D'mixed'>
> <u><choice minOccurs=3D'1' maxOccurs=3D'1'></u>
> <element ref=3D'ds:Manifest' minOccurs=3D'<u>0</u>' =
>maxOccurs=3D'unbounded'/>
> <any namespace=3D'##any' <u>processContents=3D'lax'</u> =
>minOccurs=3D'<u>0</u>' maxOccurs=3D'unbounded'/>
> <u></choice></u>
> <attribute name=3D'Id' type=3D'ID' use=3D'optional'/>=20
> <attribute name=3D'MimeType' type=3D'string' =
>use=3D'optional'/> <!-- add a grep facet -->
> <attribute name=3D'Encoding' type=3D'uriReference' =
>use=3D'optional'/>=20
> </complexType>
> </element>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT Object %Object.ANY; >
> <!ATTLIST Object =20
> Id ID #IMPLIED=20
> MimeType CDATA #IMPLIED=20
> Encoding CDATA #IMPLIED >
></pre>
>
><h2>5.0 <a id=3D"sec-AdditionalSyntax" =
>name=3D"sec-AdditionalSyntax">Additional Signature
>Syntax</a></h2>
>
><p>This section describes the optional to implement =
><code>Manifest</code> and <code>SignatureProperties</code>
>elements and describes the handling of XML processing instructions and =
>comments. With
>respect to the elements <code>Manifest</code> and =
><code>SignatureProperties</code> this
>section specifies syntax and little behavior -- it is left to the =
>application. These
>elements can appear anywhere the parent's content model permits; the =
><code>Signature</code>
>content model only permits them within <code>Object</code>.</p>
>
><h3>5.1 The <a id=3D"sec-Manifest" =
>name=3D"sec-Manifest"><code>Manifest</code></a> Element</h3>
>
><dl>
> <dt>Identifier</dt>
> <dd><code>Type=3D<a id=3D"Manifest" =
>href=3D"http://www.w3.org/2000/07/xmldsig#Manifest"
> =
>name=3D"Manifest">"http://www.w3.org/2000/07/xmldsig#Manifest"<=
>/a><br />
> </code>(this can be used within a <code>Reference</code> element to =
>identify the
> referent's type)</dd>
></dl>
>
><p>The <code>Manifest</code> element provides a list of =
><code>Reference</code>s. The
>difference from the list in <code>SignedInfo</code> is that it is =
>application defined
>which, if any, of the digests are actually checked against the objects =
>referenced and what
>to do if the object is inaccessible or the digest compare fails. If a =
><code>Manifest</code>
>is pointed to from <code>SignedInfo</code>, the digest over the =
><code>Manifest</code>
>itself will be checked by the core signature validation behavior. The =
>digests within such
>a <code>Manifest</code> are checked at application discretion. If a =
><code>Manifest</code>
>is referenced from another <code>Manifest</code>, even the overall =
>digest of this two
>level deep <code>Manifest</code> might not be checked.</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'Manifest'>=20
> <complexType content=3D'elementOnly'>
> <sequence minOccurs=3D'1' maxOccurs=3D'1'>
> <element ref=3D'ds:Reference' minOccurs=3D'1' =
>maxOccurs=3D'unbounded'/>=20
> </sequence> =20
> <attribute name=3D'Id' type=3D'ID' use=3D'optional'/>=20
> </complexType>
> </element>=20
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT Manifest (Reference+) >
> <!ATTLIST Manifest =20
> Id ID #IMPLIED >
></pre>
>
><h3>5.2 The <a id=3D"sec-SignatureProperties" =
>name=3D"sec-SignatureProperties"><code>SignatureProperties</code></a>
>Element</h3>
>
><dl>
> <dt> </dt>
> <dt>Identifier</dt>
> <dd><code>Type=3D"<a id=3D"SignatureProperty"
> href=3D"http://www.w3.org/2000/07/xmldsig#SignatureProperty" =
>name=3D"SignatureProperty">http://www.w3.org/2000/07/xmldsig#SignaturePro=
>perty</a>"<br
> />
> </code>(this can be used within a <code>Reference</code> element to =
>identify the
> referent's type)</dd>
></dl>
>
><p>Additional information items concerning the generation of the =
>signature(s) can be
>placed in a <code>SignatureProperty</code> element (i.e., date/time =
>stamp or the serial
>number of cryptographic hardware used in signature generation).</p>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'SignatureProperties'>=20
> <complexType content=3D'elementOnly'>=20
> <element ref=3D'ds:SignatureProperty' minOccurs=3D'1' =
>maxOccurs=3D'unbounded'/>=20
> <attribute name=3D'Id' type=3D'ID' use=3D'optional'/>=20
> </complexType>
> </element>=20
>
> <element name=3D'SignatureProperty'>=20
> <complexType content=3D'mixed'>=20
> <any namespace=3D'##other' <u>processContents=3D'lax'</u> =
>minOccurs=3D'1' maxOccurs=3D'unbounded'/>
> <attribute name=3D'Target' type=3D'uriReference' =
>use=3D'required'/>=20
> <attribute name=3D'Id' type=3D'ID' use=3D'optional'/>=20
> </complexType>
> </element>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT SignatureProperties (SignatureProperty+) >
> <!ATTLIST SignatureProperties =20
> Id ID #IMPLIED >
>
> <!ELEMENT SignatureProperty %Object.ANY; >
> <!ATTLIST SignatureProperty =20
> Target CDATA #REQUIRED
> Id ID #IMPLIED >
></pre>
>
><h3>5.3 <a id=3D"sec-PI" name=3D"sec-PI">Processing Instructions</a> in =
>Signature Elements</h3>
>
><p>No XML processing instructions (PIs) are used by this =
>specification.</p>
>
><p>Note that PIs placed inside <code>SignedInfo</code> by an application =
>will be signed
>unless the <code>CanonicalizationMethod</code> algorithm discards them. =
>(This is true for
>any signed XML content.) All of the <code>CanonicalizationMethod</code>s =
>specified within
>this specification retain PIs. When a PI is part of content that is =
>signed (e.g., within <code>SignedInfo</code>
>or referenced XML documents) any change to the PI will obviously result =
>in a signature
>failure.</p>
>
><h3>5.4 <a id=3D"sec-comments" name=3D"sec-comments">Comments</a> in =
>Signature Elements</h3>
>
><p>XML comments are not used by this specification.</p>
>
><p>Note that unless <code>CanonicalizationMethod</code> removes comments =
>within <code>SignedInfo</code>
>or any other referenced XML, they will be signed. Consequently, a change =
>to the comment
>will cause a signature failure. Similarly, the XML signature over any =
>XML data will be
>sensitive to comment changes unless a comment-ignoring =
>canonicalization/transform method,
>such as the Canonical XML [<a href=3D"#ref-XML-C14N">XML-C14N</a>], is =
>specified.</p>
>
><h2>6.0 <a id=3D"sec-Algorithms" =
>name=3D"sec-Algorithms">Algorithms</a></h2>
>
><p>This section identifies algorithms used with the XML digital =
>signature standard.
>Entries contain the identifier to be used in <code>Signature</code> =
>elements, a reference
>to the formal specification, and definitions, where applicable, for the =
>representation of
>keys and the results of cryptographic operations.</p>
>
><h3>6.1 <a id=3D"sec-AlgID" name=3D"sec-AlgID">Algorithm</a> Identifiers =
>and Implementation
>Requirements</h3>
>
><p>Algorithms are identified by URIs that appear as an attribute to the =
>element that
>identifies the algorithms' role (<code>DigestMethod</code>, =
><code>Transform</code>, <code>SignatureMethod</code>,
>or <code>CanonicalizationMethod</code>). All algorithms used herein take =
>parameters but in
>many cases the parameters are implicit. For example, a =
><code>SignatureMethod</code> is
>implicitly given two parameters: the keying info and the output of =
><code>CanonicalizationMethod</code>.
>Explicit additional parameters to an algorithm appear as content =
>elements within the
>algorithm role element. Such parameter elements have a descriptive =
>element name, which is
>frequently algorithm specific, and MUST be in the XML Signature =
>namespace or an algorithm
>specific namespace.</p>
>
><p>This specification defines a set of algorithms, their URIs, and =
>requirements for
>implementation. Requirements are specified over implementation, not over =
>requirements for
>signature use. Furthermore, the mechanism is extensible, alternative =
>algorithms may be
>used by signature applications.</p>
>
><p>(Note that the normative identifier is the complete URI in the table =
>though they are
>frequently abbreviated in XML syntax (e.g., =
>"&dsig;base64").)</p>
>
><table border=3D"1" cellpadding=3D"0" width=3D"100%">
> <tr>
> <td><strong>Algorithm Type</strong></td>
> <td><strong>Algorithm</strong></td>
> <td><strong>Requirements</strong></td>
> <td><strong>Algorithm URI</strong></td>
> </tr>
> <tr>
> <td>Digest</td>
> <td> </td>
> <td> </td>
> <td> </td>
> </tr>
> <tr>
> <td> </td>
> <td>SHA1</td>
> <td>REQUIRED</td>
> <td><a =
>href=3D"http://www.w3.org/2000/07/xmldsig#sha1">http://www.w3.org/2000/07=
>/xmldsig#sha1</a></td>
> </tr>
> <tr>
> <td>Encoding</td>
> <td> </td>
> <td> </td>
> <td> </td>
> </tr>
> <tr>
> <td> </td>
> <td>Base64</td>
> <td>REQUIRED</td>
> <td><a href=3D"http://www.w3.org/2000/07/xmldsig#base64"><span =
>style=3D"font-weight: =
>normal">http://www.w3.org/2000/07/xmldsig#</span>base64</a></td>
> </tr>
> <tr>
> <td>MAC</td>
> <td> </td>
> <td> </td>
> <td> </td>
> </tr>
> <tr>
> <td> </td>
> <td>HMAC-SHA1</td>
> <td>REQUIRED</td>
> <td><a =
>href=3D"http://www.w3.org/2000/07/xmldsig#hmac-sha1">http://www.w3.org/20=
>00/07/xmldsig#hmac-sha1</a></td>
> </tr>
> <tr>
> <td>Signature</td>
> <td> </td>
> <td> </td>
> <td> </td>
> </tr>
> <tr>
> <td> </td>
> <td>DSAwithSHA1<br />
> (DSS)</td>
> <td>REQUIRED</td>
> <td><a href=3D"http://www.w3.org/2000/07/xmldsig#dsa-sha1"><span =
>style=3D"font-weight: =
>normal">http://www.w3.org/2000/07/xmldsig#</span>dsa-sha1</a></td>
> </tr>
> <tr>
> <td> </td>
> <td>RSAwithSHA1</td>
> <td>RECOMMENDED</td>
> <td><a href=3D"http://www.w3.org/2000/07/xmldsig#rsa-sha1"><span =
>style=3D"font-weight: =
>normal">http://www.w3.org/2000/07/xmldsig#</span>rsa-sha1</a></td>
> </tr>
> <tr>
> <td>Canonicalization</td>
> <td> </td>
> <td> </td>
> <td> </td>
> </tr>
> <tr>
> <td> </td>
> <td>minimal</td>
> <td>RECOMMENDED</td>
> <td><a href=3D"http://www.w3.org/2000/07/xmldsig#minimal"><span =
>style=3D"font-weight: =
>normal">http://www.w3.org/2000/07/xmldsig#</span>minimal</a></td>
> </tr>
> <u john=3D"john">
> <tr>
> <td> </td>
> <td><u>Canonical XML with Comments</td>
> <td>RECOMMENDED</td>
> <td><a =
>href=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710#WithComments">http=
>://www.w3.org/TR/2000/WD-xml-c14n-20000710#WithComments</a></td>
> </tr>
> </u>
> <tr>
> <td> </td>
> <td><u>Canonical XML <u john=3D"john">(omits comments)</u></u></td>
> <td>REQUIRED</td>
> <td><a =
>href=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710">http://www.w3.org=
>/TR/2000/WD-xml-c14n-20000710</a></td>
> </tr>
> <tr>
> <td>Transform</td>
> <td> </td>
> <td> </td>
> <td> </td>
> </tr>
> <tr>
> <td> </td>
> <td>XSLT</td>
> <td>OPTIONAL</td>
> <td><a =
>href=3D"http://www.w3.org/TR/1999/REC-xslt-19991116">http://www.w3.org/TR=
>/1999/REC-xslt-19991116</a></td>
> </tr>
> <tr>
> <td> </td>
> <td>XPath</td>
> <td>RECOMMENDED</td>
> <td><a =
>href=3D"http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/T=
>R/1999/REC-xpath-19991116</a></td>
> </tr>
> <tr>
> <td> </td>
> <td>Enveloped Signature*</td>
> <td>REQUIRED</td>
> <td><a =
>href=3D"http://www.w3.org/2000/07/xmldsig#enveloped-signature">http://www=
>.w3.org/2000/07/xmldsig#enveloped-signature</a></td>
> </tr>
></table>
>
><p>* The Enveloped Signature transform removes the =
><code>Signature</code> element from the
>calculation of the signature when the signature is within the=20
><strike john=3D"john"><u>element</u></strike> <u =
>john=3D"john">content</u> that it is
>being signed. This MAY be implemented via the RECOMMENDED XPath =
>specification specified in
>6.6.4: <a href=3D"#sec-EnvelopedSignature">Enveloped Signature =
>Transform</a>; it MUST have
>the same effect as that specified by the <strike =
>john=3D"john">XPath</strike>=20
><u john=3D"john"><a href=3D"#sec-XPath">XPath Transform</a></u> =
>specification.</p>
>
><h3>6.2 <a id=3D"sec-MessageDigests" name=3D"sec-MessageDigests">Message =
>Digests</a></h3>
>
><p>Only one digest algorithm is defined herein. However, it is expected =
>that one or more
>additional strong digest algorithms will be developed in connection with =
>the US Advanced
>Encryption Standard effort. Use of <a =
>href=3D"http://www.ietf.org/rfc/rfc1321.txt">MD5</a> [<a
>href=3D"#ref-MD5">MD5</a>] is NOT RECOMMENDED because recent advances in =
>cryptography have
>cast doubt on its strength.</p>
>
><h4>6.2.1 <a id=3D"sec-SHA-1" name=3D"sec-SHA-1">SHA-1</a></h4>
>
><dl>
> <dt>Identifier:</dt>
> <dd><a id=3D"sha1" href=3D"http://www.w3.org/2000/07/xmldsig#sha1" =
>name=3D"sha1">http://www.w3.org/2000/07/xmldsig#sha1</a></dd>
></dl>
>
><p>The <a href=3D"http://csrc.nist.gov/fips/fip180-1.pdf">SHA-1</a> =
>algorithm [<a
>href=3D"#ref-SHA-1">SHA-1</a>] takes no explicit parameters. An example =
>of an SHA-1
>DigestAlg element is:</p>
>
><pre class=3D"xml-example">
><code><DigestMethod Algorithm=3D"</code><span
>style=3D"font-weight: =
>normal">&dsig;</span><code>sha1"/></code>=20
></pre>
>
><p>A SHA-1 digest is a 160-bit string. The content of the DigestValue =
>element shall be the
>base64 encoding of this bit string viewed as a 20-octet octet stream. =
>For example, the
>DigestValue element for the message digest:</p>
>
><pre class=3D"xml-example">
> A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
></pre>
>
><p>from Appendix A of the SHA-1 standard would be:</p>
>
><pre class=3D"xml-example">
> <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=3D</DigestValue>
></pre>
>
><h3>6.3 <a id=3D"sec-MACs" name=3D"sec-MACs">Message Authentication =
>Codes</a></h3>
>
><p>MAC algorithms take two implicit parameters, their keying material =
>determined from <code>KeyInfo</code>
>and the octet stream output by <code>CanonicalizationMethod</code>. MACs =
>and signature
>algorithms are syntactically identical but a MAC implies a shared secret =
>key.</p>
>
><h4>6.3.1 <a id=3D"sec-HMAC" name=3D"sec-HMAC">HMAC</a></h4>
>
><dl>
> <dt>Identifier:</dt>
> <dd><a id=3D"hmac-sha1" name=3D"hmac-sha1" =
>href=3D"http://www.w3.org/2000/07/xmldsig#hmac-sha1">http://www.w3.org/20=
>00/07/xmldsig#hmac-sha1</a></dd>
></dl>
>
><p>The <a href=3D"ftp://ftp.isi.edu/in-notes/rfc2104.txt">HMAC</a> =
>algorithm (RFC2104 [<a
>href=3D"#ref-HMAC">HMAC</a>]) takes the truncation length in bits as a =
>parameter; if the
>parameter is not specified then all the bits of the hash are output. An =
>example of an HMAC
><code>SignatureMethod</code> element:</p>
>
><pre class=3D"xml-example">
> <SignatureMethod Algorithm=3D"&dsig;hmac-sha1">
> <HMACOutputLength>128</HMACOutputLength>
> </SignatureMethod>
></pre>
>
><p>The output of the HMAC algorithm is ultimately the output (possibly =
>truncated) of the
>chosen digest algorithm. This value shall be base64 encoded in the same =
>straightforward
>fashion as the output of the digest algorithms. Example: the =
>SignatureValue element for
>the HMAC-SHA1 digest</p>
>
><pre class=3D"xml-example">
> 9294727A 3638BB1C 13F48EF8 158BFC9D
></pre>
>
><p>from the test vectors in [<a href=3D"#ref-HMAC">HMAC</a>] would =
>be</p>
>
><pre class=3D"xml-example">
><SignatureValue>kpRyejY4uxwT9I74FYv8nQ=3D=3D</SignatureValue>=
>
></pre>
>
><pre class=3D"xml-dtd">
> Schema Definition:
>
> <element name=3D'HMACOutputLength' type=3D'integer' =
>minOccurs=3D'0' maxOccurs=3D'1'/>
></pre>
>
><pre class=3D"xml-dtd">
> DTD:
>
> <!ELEMENT HMACOutputLength (#PCDATA)>
></pre>
>
><h3>6.4 <a id=3D"sec-SignatureAlg" name=3D"sec-SignatureAlg">Signature =
>Algorithms</a></h3>
>
><p>Signature algorithms take two implicit parameters, their keying =
>material determined
>from <code>KeyInfo</code> and the octet stream output by =
><code>CanonicalizationMethod</code>.
>Signature and MAC algorithms are syntactically identical but a signature =
>implies public
>key cryptography.</p>
>
><h4>6.4.1 <a id=3D"sec-DSA" name=3D"sec-DSA">DSA</a></h4>
>
><dl>
> <dt>Identifier:</dt>
> <dd><a id=3D"dsa-sha1" name=3D"dsa-sha1" =
>href=3D"http://www.w3.org/2000/07/xmldsig#dsa-sha1">http://www.w3.org/200=
>0/07/xmldsig#dsa-sha1</a></dd>
></dl>
>
><p>The DSA algorithm [<a href=3D"#ref-DSS">DSS</a>] takes no explicit =
>parameters. An example
>of a DSA <code>SignatureMethod</code> element is:</p>
>
><pre class=3D"xml-example">
> <code><SignatureMethod Algorithm=3D"</code><span
>style=3D"font-weight: =
>normal">&dsig;</span><code>dsa"/></code>
></pre>
>
><p>The output of the DSA algorithm consists of a pair of integers =
>usually referred by the
>pair (r, s). The signature value consists of the base64 encoding of the =
>concatenation of
>two octet-streams that respectively result from the octet-encoding of =
>the values r and s.
>Integer to octet-stream conversion must be done according to the I2OSP =
>operation defined
>in the <a href=3D"ftp://ftp.isi.edu/in-notes/rfc2437.txt">RFC 2437</a> =
>[<a href=3D"#ref-PKCS1">PKCS1</a>]
>specification with a k parameter equal to 20. For example, the =
>SignatureValue element for
>a DSA signature (r, s) with values specified in hexadecimal:</p>
>
><pre class=3D"xml-example">
> <code>r =3D 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0</code>=20
> <code>s =3D 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8</code>=20
></pre>
>
><p>from the example in Appendix 5 of the DSS standard would be</p>
>
><pre class=3D"xml-example">
> <code><SignatureValue></code>
> =
><code>i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA=3D=3D</Si=
>gnatureValue></code>
></pre>
>
><p>DSA key values have the following set of fields: P, Q, G and Y are =
>mandatory when
>appearing as a key value, J, seed and pgenCounter are optional but =
>SHOULD be present. (The
>seed and pgenCounter fields MUST appear together or be absent). All =
>parameters are encoded
>as base64 values.</p>
>
><pre class=3D"xml-dtd">
> <code>Schema:</code>
>
> <element name=3D'DSAKeyValue'>=20
> <complexType content=3D'elementOnly'>=20
> <sequence minOccurs=3D'1' maxOccurs=3D'1'>
> <element name=3D'P' type=3D'ds:CryptoBinary' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element name=3D'Q' type=3D'ds:CryptoBinary' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element name=3D'G' type=3D'ds:CryptoBinary' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element name=3D'Y' type=3D'ds:CryptoBinary' minOccurs=3D'1' =
>maxOccurs=3D'1'/>=20
> <element name=3D'J' type=3D'ds:CryptoBinary' minOccurs=3D'0' =
>maxOccurs=3D'1'/>=20
> </sequence>
> <sequence minOccurs=3D'0' maxOccurs=3D'1'>
> <element name=3D'Seed' type=3D'ds:CryptoBinary' =
>minOccurs=3D'1' maxOccurs=3D'1'/>=20
> <element name=3D'PgenCounterQ' type=3D'ds:CryptoBinary' =
>minOccurs=3D'1' maxOccurs=3D'1'/>=20
> </sequence>
> </complexType>
> </element>
>
></pre>
>
><pre class=3D"xml-dtd">
> <code>DTD:</code>
>
> <!ELEMENT DSAKeyValue (P, Q, G, Y, J?, (Seed, PgenCounter)?) >=20
> <!ELEMENT P (#PCDATA) >
> <!ELEMENT Q (#PCDATA) >
> <!ELEMENT G (#PCDATA) >
> <!ELEMENT Y (#PCDATA) >
> <!ELEMENT J (#PCDATA) >
> <!ELEMENT Seed (#PCDATA) >
> <!ELEMENT PgenCounter (#PCDATA) >
></pre>
>
><h4>6.4.2 <a id=3D"sec-PKCS1" name=3D"sec-PKCS1">PKCS1</a></h4>
>
><dl>
> <dt>Identifier:</dt>
> <dd><a id=3D"rsa-sha1" =
>href=3D"http://www.w3.org/2000/07/xmldsig#rsa-sha1" =
>name=3D"rsa-sha1">http://www.w3.org/2000/07/xmldsig#rsa-sha1</a></dd>
></dl>
>
><p>Arbitrary-length integers (e.g. "bignums" such as RSA =
>modulii) are
>represented in XML as octet strings. The integer value is first =
>converted to a "big
>endian" bitstring. The bitstring is then padded with leading zero =
>bits so that the
>total number of bits =3D=3D 0 mod 8 (so that there are an even number of =
>bytes). If the
>bitstring contains entire leading bytes that are zero, these are removed =
>(so the
>high-order byte is always non-zero). This octet string is then Base64 =
>encoded. (The
>conversion from integer to octet string is equivalent to IEEE P1363's =
>I2OSP [<a
>href=3D"#ref-P1363">P1363</a>] with minimal length).</p>
>
><p>The expression "RSA algorithm" as used in this draft refers =
>to the
>RSASSA-PKCS1-v1_5 algorithm described in <a =
>href=3D"ftp://ftp.isi.edu/in-notes/rfc2437.txt">RFC
>2437</a> [<a href=3D"#ref-PKCS1">PKCS1</a>]. (Note that support for =
>PKCS1 Version 2 is
>planned as soon as that standard is finalized). The RSA algorithm takes =
>no explicit
>parameters. An example of an RSA SignatureMethod element is:</p>
>
><pre class=3D"xml-example">
> <code><SignatureMethod Algorithm=3D"</code><span
>style=3D"font-weight: =
>normal">&dsig;</span><code>rsa-sha1"/></code>
></pre>
>
><p>The <code>SignatureValue</code> content for an RSA signature shall be =
>the base64
>encoding of the octet string. Signatures are interpreted as unsigned =
>integers. A signature
>MAY contain a pre-pended algorithm object identifier, but the =
>availability of an ASN.1
>parser and recognition of OIDs is not required of a signature =
>verifier.</p>
>
><pre class=3D"xml-example">
> =
><SignatureValue>F8aupsHjmbIApjAH4AVYjcsmQkXChyjGYleVJe1KLAmmXWww=20
> 3PqkDPUMojithbwbVWVJJ0UhdT407nl0fBrohvkunDq8gzfGkjvO+zDJws1HkRtZ=20
> vl1IIBLVWf/qgcLJOgid/2A66niC20GwKcJgIp3o1L+6l7LlSKiZ/CkgDO4=3D=20
> </SignatureValue>
></pre>
>
><p>RSA key values have two fields: Modulus and Exponent</p>
>
><pre class=3D"xml-example">
> <RSAKeyValue>=20
> <Exponent>AQAB</Exponent>=20
> =
><Modulus>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6=
>W=20
> jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV=20
> 5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=3D=20
> </Modulus>=20
> </RSAKeyValue>
></pre>
>
><pre class=3D"xml-dtd">
> <code>Schema:</code>
>
> <element name=3D'RSAKeyValue'>=20
> <complexType content=3D'elementOnly'>=20
> <element name=3D'Modulus' type=3D'ds:CryptoBinary' =
>minOccurs=3D'1' maxOccurs=3D'1'/>=20
> <element name=3D'Exponent' type=3D'ds:CryptoBinary' =
>minOccurs=3D'1' maxOccurs=3D'1'/>=20
> </complexType>=20
> </element>
></pre>
>
><pre class=3D"xml-dtd">
> <code>DTD:</code>
>
> <!ELEMENT RSAKeyValue (Modulus, Exponent) >=20
> <!ELEMENT Modulus (#PCDATA) >
> <!ELEMENT Exponent (#PCDATA) >
></pre>
>
><h3>6.5 <a id=3D"sec-c14nAlg" name=3D"sec-c14nAlg">Canonicalization =
>Algorithms</a></h3>
>
><p><u>Canonicalization algorithms take two implicit parameter when they =
>appear as a <code>CanonicalizationMethod</code>
>within the <code>SignedInfo</code> element: the content and its charset. =
>The charset is
>derived according to the rules of the transport protocols and media =
>types (e.g, RFC2376 [<a
>href=3D"#ref-XML-MT">XML-MT</a>] defines the media types for XML). This =
>information is
>necessary to correctly sign and verify documents and often requires =
>careful server side
>configuration. </u></p>
>
><p><u>Various canonicalization algorithms require conversion to [<a =
>href=3D"#ref-UTF-8">UTF-8</a>].The
>two algorithms below understand at least [<a =
>href=3D"#ref-UTF-8">UTF-8</a>] and [<a
>href=3D"#ref-UTF-16">UTF-16</a>] as input encodings. We RECOMMEND that =
>externally specified
>algorithms do the same. Knowledge of other encodings is =
>OPTIONAL.</u></p>
>
><p><u>Various canonicalization algorithms transcode from a non-Unicode =
>encoding to
>Unicode. The two algorithms below perform text normalization during =
>transcoding [<a
>href=3D"#ref-NFC">NFC</a>]. We RECOMMENDED that externally specified =
>canonicalization
>algorithms do the same. (Note, there can be ambiguities in converting =
>existing charsets to
>Unicode, for an example see the XML Japanese Profile [<a =
>href=3D"#ref-XML-Japanese">XML-Japanese</a>]
>NOTE.)</u></p>
>
><h4>6.5.1 <a id=3D"sec-Minimal" name=3D"sec-Minimal">Minimal</a> =
>Canonicalization</h4>
>
><dl>
> <dt>Identifier:</dt>
> <dd><a id=3D"minimal" =
>href=3D"http://www.w3.org/2000/07/xmldsig#minimal" =
>name=3D"minimal">http://www.w3.org/2000/07/xmldsig#minimal</a></dd>
></dl>
>
><p>An example of a minimal canonicalization element is:</p>
>
><pre class=3D"xml-example">
> <code><CanonicalizationMethod =
>Algorithm=3D"&dsig;minimal"/></code>=20
></pre>
>
><p>The minimal canonicalization algorithm:=20
>
><ul>
> <li>converts the character encoding to UTF-8 (without any byte order =
>mark (BOM)).=20
> <u john=3D"john">If an encoding is given in the XML declaration, it =
>must be removed.</u>
> <u>Implementations MUST understand at least [<a =
>href=3D"#ref-UTF-8">UTF-8</a>] and [<a href=3D"#ref-UTF-16">UTF-16</a>]
> as input encodings. Non-Unicode to Unicode transcoding MUST perform =
>text normalization [<a
> href=3D"#ref-NFC">NFC</a>].</u></li>
> <li>normalizes line endings as provided by [<a =
>href=3D"#ref-XML">XML</a>]. (See section 7: <a
> href=3D"#sec-XML-Canonicalization">XML and Canonicalization and =
>Syntactical Considerations</a>.)</li>
></ul>
>
><u john=3D"john">
>
><p>This algorithm requires as input the octet stream of the resource to =
>be processed.
>However, the actual input to this algorithm may be an XPath node-set (or =
>a sufficiently=20
>functional replacement implemented by the application). This is true =
>when canonicalizing
><code>SignedInfo</code>, the result of a same-document URI dereference, =
>or the output
>of certain types of transforms. In such cases, it is assumed that the =
>application has access to
>the necessary portions of the original octet stream such that the =
>algorithm's conversions
>can be done without XML processing. The XPath node-set (or sufficiently =
>functional replacement)=20
>exists solely to indicate the portions of the original octet stream =
>required to form the output. =20
>The algorithm outputs an octet stream.</p>
>
><p>Since this algorithm will typically be implemented without the formal =
>use of XPath
>node-sets, note that comments are omitted from same-document URI =
>references created by
>the null URI or barename XPointers. We RECOMMEND using the full =
>XPointer equivalents
>of these URIs that retain comments (see <a =
>href=3D"#sec-Reference">Section 4.3.3</a>) due to=20
>the difficulty of removing comments from a surface string representation =
>of XML. =20
>Note that the comment start token (<code><!--</code>) can appear as =
>data (i.e. not as a=20
>begin comment mark) inside attribute values, CDATA sections, processing =
>instructions, and certain=20
>places in the document type declaration (specifically, in entity and =
>notation declarations=20
>where the ExternalID permits a SystemLiteral).</p>
></u>
>
><h4>6.5.2 <a id=3D"sec-Canonical" name=3D"sec-Canonical">Canonical</a> =
>XML</h4>
>
><dl>
> <dt>Identifier <u john=3D"john">for REQUIRED Canonical XML (omits =
>comments)</u>:</dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710">http://www.w3.org=
>/TR/2000/WD-xml-c14n-20000710</a></dd>
></dl>
>
><u john=3D"john">
><dl>
> <dt>Identifier <u john=3D"john">for Canonical XML with =
>Comments</u>:</dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710#WithComments">http=
>://www.w3.org/TR/2000/WD-xml-c14n-20000710#WithComments</a></dd>
></dl>
></u>
>
><p>An example of an XML canonicalization element is:</p>
>
><pre class=3D"xml-example">
> <code><CanonicalizationMethod =
>Algorithm=3D"</code>http://www.w3.org/TR/2000/WD-xml-c14n-20000710<c=
>ode>"/></code>
></pre>
>
><p>The normative specification of Canonical XML is [<a =
>href=3D"#ref-XML-C14N">XML-C14N</a>].
><u john=3D"john">The algorithm is capable of taking as input either an =
>octet stream or an XPath node-set=20
>(or sufficiently functional alternative). The algorithm produces an =
>octet stream as output.
>Canonical XML is easily parameterized to omit or retain =
>comments.</u></p>
>
><h3>6.6 <a id=3D"sec-TransformAlg" =
>name=3D"sec-TransformAlg"><code>Transform</code></a>
>Algorithms</h3>
>
><p>A <code>Transform</code> algorithm has a single implicit parameters: =
>an octet stream
>from the <code>Reference</code> or the output of an earlier =
><code>Transform</code>.</p>
>
><p>Application developers are strongly encouraged to support all =
>transforms listed in this
>section as RECOMMENDED unless the application environment has resource =
>constraints that
>would make such support impractical. Compliance with this recommendation =
>will maximize
>application interoperability and libraries should be available to enable =
>support of these
>transforms in applications without extensive development.</p>
>
><h4>6.6.1 <a id=3D"sec-Canonicalization" =
>name=3D"sec-Canonicalization">Canonicalization</a></h4>
>
><p>Any canonicalization algorithm that can be used for =
><code>CanonicalizationMethod</code>
>can be used as a <code>Transform</code>.</p>
>
><h4>6.6.2 <a id=3D"sec-Base-64" name=3D"sec-Base-64">Base64</a></h4>
>
><dl>
> <dt>Identifiers:</dt>
> <dd><a id=3D"base64" href=3D"http://www.w3.org/2000/07/xmldsig#base64" =
>name=3D"base64">http://www.w3.org/2000/07/xmldsig#base64</a></dd>
></dl>
>
><p>The normative specification for base 64 decoding transforms is [<a =
>href=3D"#ref-MIME">MIME</a>].
>The base64 <code>Transform</code> element has no content. The input is =
>decoded by the
>algorithms. This transform is useful if an application needs to sign the =
>raw data
>associated with the encoded content of an element.</p>
>
><u john=3D"john">
><p>This transform requires an octet stream for input. If an XPath =
>node-set (or sufficiently
>functional alternative) is given as input, then it is converted to an =
>octet stream by
>taking the string-value of the node-set (or logically equivalent =
>operation). Thus, if
>an XML element is identified by a barename XPointer in the =
><code>Reference</code> URI, and
>its content consists solely of base-64 encoded character data, then this =
>transform automatically
>strips away the start and end tags of the identified elements. The =
>output of this transform=20
>is an octet stream.</p>
></u>
>
><h4>6.6.3 <a name=3D"sec-XPath">XPath</a> Filtering</h4>
>
><dl>
> <dt>Identifier:</dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/T=
>R/1999/REC-xpath-19991116</a></dd>
></dl>
>
><u john=3D"john">
><p>The normative specification for XPath expression evaluation is [<a
>href=3D"http://www.w3.org/TR/xmldsig-core/#ref-XPath">XPath</a>]. The =
>XPath expression
>to be evaluated appears as the character content of a transform =
>parameter subelement
>named <code>XPath</code>.</p>
>
><p>The input required by this transform is an XPath node-set. Note that =
>if the actual input
>is an XPath node-set resulting from a null URI or barename XPointer =
>dereference, then there=20
>may not be comment nodes. If the actual input is an octet stream, then =
>the application MUST convert=20
>the octet stream to an XPath node-set suitable for use by Canonical XML =
>with Comments (a=20
>subsequent application of the REQUIRED Canonical XML algorithm would =
>strip away these comments). =20
>In other words, the input node-set should be equivalent to the one that =
>would be created by=20
>the following process:</p>
>
><ol>
><li>Initialize an XPath evaluation context by setting the initial node =
>equal to=20
>the input XML document's root node, and set the context position and =
>size to 1.</li>
><li>Evaluate the XPath expression <code>(//. | //@* | =
>//namespace::*)</code></li>
></ol>
>
><p>The transform output is also an XPath node-set. The XPath expression =
>appearing
>in the <code>XPath</code> parameter is evaluated once for each node in =
>the input node-set.
>The result is converted to a boolean. If the boolean is true, then the =
>node is included
>in the output node-set. If the boolean is false, then the node is =
>omitted from the output
>node-set.</p>
>
><p>The primary purpose of this transform is to ensure that only =
>specifically defined=20
>changes to the input XML document are permitted after the signature is =
>affixed. This is=20
>done by omitting precisely those nodes that are allowed to change once =
>the signature is=20
>affixed, and including all other input nodes in the output. It is the =
>responsibility of the=20
>XPath expression author to include all nodes whose change could affect =
>the interpretation=20
>of the transform output in the application context.</p>
>
><p>An important scenario would be a document requiring two enveloped =
>signatures. =20
>Each signature must omit itself from its own digest calculations, but it =
>is also necessary=20
>to exclude the second signature element from the digest calculations of =
>the first signature=20
>so that adding the second signature does not break the first =
>signature.</p>
>
><p>The XPath transform establishes the following evaluation context for =
>each node of=20
>the input node-set:=20
>
><ul>
> <li>A <b>context node</b> equal to a node of the input node-set.</li>
> <li>A <b>context position</b>, initialized to 1.</li>
> <li>A <b>context size</b>, initialized to 1.</li>
> <li>A <b>library of functions</b> equal to the function set defined in =
><a
> href=3D"http://www.w3.org/TR/xmldsig-core/#ref-XPath">XPath</a> plus =
>a function named <b><a
> href=3D"#function-here">here</a></b>.</li>
> <li>A set of variable bindings. No means for initializing these is =
>defined. Thus, the set of
> variable bindings used when evaluating the XPath expression is =
>empty, and use of a
> variable reference in the XPath expression results in an error.</li>
> <li>The set of namespace declarations in scope for the XPath =
>expression.</li>
></ul>
>
><p>As a result of the context node setting, the XPath expressions =
>appearing in this
>transform will be quite similar to those used in XSLT template matching, =
>except that the
>size and position are always 1 to reflect the fact that the transform is =
>automatically
>visiting every node (in XSLT, one recursively calls the command=20
><code>apply-templates</code> to visit the nodes of the input tree).</p>
></u>
>
><strike john=3D"john">
><p>The <a =
>href=3D"http://www.w3.org/TR/xmldsig-core/#ref-XPath">XPath</a> =
>transform output
>is the result of applying the XML canonicalization algorithm [<a =
>href=3D"#ref-XML-C14N">XML-C14N</a>],
>parameterized by a given XPath expression, to the XML document received =
>as the transform
>input. The XPath expression appears as the character content of a =
>transform parameter
>subelement named <code>XPath</code>.</p>
>
><p>The primary purpose of this transform is to ensure that only =
>specifically defined
>changes to the input XML document are permitted after the signature is =
>affixed. The XPath
>expression can be created such that it includes all elements except =
>those meeting specific
>criteria. It is the responsibility of the XPath expression author to =
>ensure that all
>necessary information has been included in the output such that =
>modification of the
>excluded information does not affect the interpretation of the transform =
>output in the
>application context.</p>
>
><p>The XPath transform establishes the following evaluation context for =
>the XML
>canonicalization algorithm:=20
>
><ul>
> <li>A <b>context node</b>, initialized to the input XML document's =
>root node.</li>
> <li>A <b>context position</b>, initialized to 1.</li>
> <li>A <b>context size</b>, initialized to 1.</li>
> <li>A <b>library of functions</b> equal to the function set defined in =
><a
> href=3D"http://www.w3.org/TR/xmldsig-core/#ref-XPath">XPath</a> plus =
>a function named <b><a
> href=3D"#function-here">here</a></b>.</li>
> <li>A set of variable bindings. No means for initializing these is =
>defined. Thus, the set of
> variable bindings used when evaluating the XPath expression is =
>empty, and use of a
> variable reference in the XPath expression results in an error.</li>
> <li>The set of namespace declarations in scope for the XPath =
>expression.</li>
> <li>The XPath expression appearing as the character content of the =
><code>XPath</code>
> parameter element.</li>
></ul>
>
></strike>
>
><p>The function definition for <code>here()</code> is consistent with =
>its definition in
>XPointer. It is defined as follows:</p>
>
><p><a name=3D"function-here"><b>Function:</b> <i>node-set</i> =
><b>here</b>()</a></p>
>
><p>The <b><a href=3D"#function-here">here</a></b> function returns a =
>node-set containing the
>single node that directly bears the XPath expression. The node could be =
>of any type
>capable of directly bearing text, especially text and attribute. This =
>expression results
>in an error if the containing XPath expression does not appear in=20
><strike john=3D"john">an XML document</strike><u john=3D"john">the same =
>XML document
>against which the XPath expression is being evaluated</u>.</p>
>
><p>As an example, consider creating an enveloped signature (a =
><code>Signature</code>
>element that is a descendant of an element being signed). Although the =
>signed content
>should not be changed after signing, the elements within the =
><code>Signature</code>
>element are changing (e.g. the digest value must be put inside the =
><code>DigestValue</code>
>and the <code>SignatureValue</code> must be subsequently calculated). =
>One way to prevent
>these changes from invalidating the digest value in =
><code>DigestValue</code> is to add an
>XPath <code>Transform</code> that omits all <code>Signature</code> =
>elements and their
>descendants. For example,</p>
>
><p class=3D"xml-example"><code> <Document><br />
> ... <br />
> <Signature xmlns=3D"&dsig;"><br />
> <SignedInfo><br />
> ...<br />
> <Reference =
>URI=3D""><br />
> <Transforms><br =
>/>
> =
> <Transform
>Algorithm=3D"http://www.w3.org/TR/1999/REC-xpath-19991116"><=
>br />
> =
> <XPath
>xmlns:dsig=3D"&dsig;"><br />
>
> &=
>nbsp;=20
><strike john=3D"john"> (//. | //@* | =
>//namespace::*)[not(ancestor-or-self::dsig:Signature)] </strike>
><u john=3D"john"> not(ancestor-or-self::dsig:Signature)</u>
><br />
> =
></XPath><br
>/>
> =
> </Transform><br />
> </Transforms><br =
>/>
> <DigestMethod
>Algorithm=3D"http://www.w3.org/2000/07/xmldsig#sha1"/><br =
>/>
> =
> <DigestValue></DigestValue><br
>/>
> </Reference><br />
> </SignedInfo><br />
> =
> <SignatureValue></SignatureValue><br />
> </Signature><br />
> ...<br />
> </Document></code></p>
>
><strike john=3D"john">
><p>The subexpression <code>(//. | //@* | //namespace::*)</code> means =
>that all nodes in
>the entire parse tree starting at the root node are candidates for the =
>result node-set.
>For each node candidate, the node is included in the resultant node-set =
>if and only if the
>node test (the boolean expression in the square brackets) evaluates to =
>"true"
>for that node. The node test returns true for all nodes except nodes =
>that either have or
>have an ancestor with a tag of <code>Signature</code>.</p>
></strike>
>
><u john=3D"john">
><p>Due to the null <code>Reference</code> URI in this example, the XPath =
>transform input=20
>node-set contains all nodes in the entire parse tree starting at the =
>root node (except
>the comment nodes). For each node in this node-set, the node is =
>included in the output=20
>node-set except if the node or one of its ancestors has a tag of =
><code>Signature</code>=20
>that is in the namespace given by the replacement text for the entity =
><code>&dsig;</code>.</p>
></u>
>
><p>A more elegant solution uses the <b><a =
>href=3D"#function-here">here</a></b> function to
>omit only the <code>Signature</code> containing the XPath Transform, =
>thus allowing
>enveloped signatures to sign other signatures. In the example above, use =
>the <code>XPath</code>
>element:</p>
>
><strike john=3D"john">
><p class=3D"xml-example"><code> <XPath
>xmlns:dsig=3D"&dsig;">(//. | //@* | //namespace::*)<br =
>/>
> [count(ancestor-or-self::dsig:Signature | =
>here()/ancestor::dsig:Signature[1])
>><br />
> =
>count(ancestor-or-self::dsig:Signature)]</XPath></code></p>
></strike>
>
><u john=3D"john">
><p class=3D"xml-example"><code> <XPath
>xmlns:dsig=3D"&dsig;"><br />
> count(ancestor-or-self::dsig:Signature | =
>here()/ancestor::dsig:Signature[1]) ><br />
> =
>count(ancestor-or-self::dsig:Signature)</XPath></code></p>
></u>
>
><p>Since the XPath equality operator converts node sets to string values =
>before
>comparison, we must instead use the XPath union operator (|). For each =
>node of the
>document, the predicate expression is true if and only if the node-set =
>containing the node
>and its <code>Signature</code> element ancestors does not include the =
>enveloped <code>Signature</code>
>element containing the XPath expression (the union does not produce a =
>larger set if the
>enveloped <code>Signature</code> element is in the node-set given by =
><code>ancestor-or-self::Signature</code>).</p>
>
><strike john=3D"john">
><p>It is RECOMMENDED that the XPath be constructed such that the result =
>of this operation
>is a well-formed XML document. This should be the case if the root =
>element of the input
>resource is included by the XPath (even if a number of its descendant =
>nodes are omitted by
>the XPath expression). It is also RECOMMENDED that nodes should not be =
>omitted from the
>input if they affect the interpretation of the output nodes in the =
>application context.
>The XPath expression author is responsible for this since the XPath =
>expression author
>knows the application context.</p>
></strike>
>
><h4>6.6.4 <a name=3D"sec-EnvelopedSignature">Enveloped Signature</a> =
>Transform</h4>
>
><dl>
> <dt>Identifier:</dt>
> <dd><a href=3D"http://www.w3.org/2000/07/xmldsig#enveloped-signature"
> =
>name=3D"enveloped-signature">http://www.w3.org/2000/07/xmldsig#enveloped-=
>signature</a></dd>
></dl>
>
><p>An enveloped signature transform <b><i>T</i></b> removes the whole =
><code>Signature</code>
>element containing <b><i>T</i></b> from the digest calculation of the =
><code>Reference</code>
>element containing <b><i>T</i></b>. The entire string of characters used =
>by an XML
>processor to match the <code>Signature</code> with the XML production =
><code>element</code>
>is removed. The output of the transform is equivalent to the output that =
>would result from
>replacing <b><i>T</i></b> with an XPath transform containing the =
>following <code>XPath</code>
>parameter element:</p>
>
><strike john=3D"john">
><p class=3D"xml-example"><code> <XPath
>xmlns:dsig=3D"&dsig;">(//. | //@* | //namespace::*)<br =
>/>
> [count(ancestor-or-self::dsig:Signature | =
>here()/ancestor::dsig:Signature[1])
>><br />
> =
>count(ancestor-or-self::dsig:Signature)]</XPath></code></p>
></strike>
>
><u john=3D"john">
><p class=3D"xml-example"><code> <XPath
>xmlns:dsig=3D"&dsig;"><br />
> count(ancestor-or-self::dsig:Signature | =
>here()/ancestor::dsig:Signature[1])
>><br />
> =
>count(ancestor-or-self::dsig:Signature)</XPath></code></p>
></u>
>
><p><u john=3D"john">The input and output requirements of this transform =
>are identical
>to those of the XPath transform.</u> Note that it is not necessary to =
>use an XPath expression=20
>evaluator to create this transform. However, this transform MUST produce =
>output in exactly the=20
>same manner as the XPath transform parameterized by the XPath expression =
>above.</p>
>
><h4>6.6.5 <a name=3D"sec-XSLT">XSLT</a> Transform</h4>
>
><dl>
> <dt>Identifier:</dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/1999/REC-xslt-19991116">http://www.w3.org/TR=
>/1999/REC-xslt-19991116</a></dd>
></dl>
>
><u john=3D"john">
><p>The normative specification for XSL Transformations is [<a
>href=3D"http://www.w3.org/TR/xmldsig-core/#ref-XSLT">XSLT</a>]. The XSL =
>stylesheet or
>transform to be evaluated appears as the character content of a =
>transform parameter subelement
>named <code>XSLT</code>. This transform requires an octet stream as =
>input. If the
>actual input is an XPath node-set, then it should be converted to an =
>octet stream
>using the required Canonical XML (omit comments) [<a =
>href=3D"#ref-XML-C14N">XML-C14N</a>]. =20
>The output of this transform is an octet stream. The processing rules =
>for the XSL stylesheet
>or transform element are stated in the XSLT specification=20
>[<a href=3D"http://www.w3.org/TR/xmldsig-core/#ref-XSLT">XSLT</a>].<p>
>
><p>We RECOMMEND that XSLT Transform authors use an output method
>of <code>xml</code> for XML and HTML. We RECOMMEND inserting a =
>Transform after the
>XSLT Transform to perform the required Canonical XML (omit comments). =
>These steps will=20
>help to ensure interoperability of the resulting signatures among =
>applications that=20
>support the XSLT transform. Note that if the output is actually HTML, =
>then the result=20
>of these steps is logically equivalent [<a =
>href=3D"#ref-XHTML">XHTML</a>].</p>
></u>
>
><strike john=3D"john">
><p>The <tt>Transform</tt> element contains a single parameter child =
>element called <code>XSLT</code>,
>whose content MUST conform to the XSL Transforms [<a
>href=3D"http://www.w3.org/TR/xmldsig-core/#ref-XSLT">XSLT</a>] language =
>syntax. The
>processing rules for the XSLT transform are stated in the XSLT =
>specification [<a
>href=3D"http://www.w3.org/TR/xmldsig-core/#ref-XSLT">XSLT</a>].</p>
></strike>
>
><h2>7.0 <a id=3D"sec-XML-Canonicalization" =
>name=3D"sec-XML-Canonicalization">XML
>Canonicalization</a> and Syntax Constraint Considerations</h2>
>
><p>Digital signatures only work if the verification calculations are =
>performed on exactly
>the same bits as the signing calculations. If the surface representation =
>of the signed
>data can change between signing and verification, then some way to =
>standardize the
>changeable aspect must be used before signing and verification. For =
>example, even for
>simple ASCII text there are at least three widely used line ending =
>sequences. If it is
>possible for signed text to be modified from one line ending convention =
>to another between
>the time of signing and signature verification, then the line endings =
>need to be
>canonicalized to a standard form before signing and verification or the =
>signatures will
>break.</p>
>
><p>XML is subject to surface representation changes and to processing =
>which discards some
>surface information. For this reason, XML digital signatures have a =
>provision for
>indicating canonicalization methods in the signature so that a verifier =
>can use the same
>canonicalization as the signer.</p>
>
><p>Throughout this specification we distinguish between the =
>canonicalization of a <code>Signature</code>
>element and other signed XML data objects. It is possible for an =
>isolated XML document to
>be treated as if it were binary data so that no changes can occur. In =
>that case, the
>digest of the document will not change and it need not be canonicalized =
>if it is signed
>and verified as such. However, XML that is read and processed using =
>standard XML parsing
>and processing techniques is frequently changed such that some of its =
>surface
>representation information is lost or modified. In particular, this will =
>occur in many
>cases for the <code>Signature</code> and enclosed =
><code>SignedInfo</code> elements since
>they, and possibly an encompassing XML document, will be processed as =
>XML.</p>
>
><p>Similarly, these considerations apply to <code>Manifest</code>, =
><code>Object</code>,
>and <code>SignatureProperties</code> elements if those elements have =
>been digested, their <code>DigestValue</code>
>is to be checked, and they are being processed as XML.</p>
>
><p>The kinds of changes in XML that may need to be canonicalized can be =
>divided into three
>categories. There are those related to the basic [<a =
>href=3D"#ref-XML">XML</a>], as
>described in 7.1 below. There are those related to [<a =
>href=3D"#ref-DOM">DOM</a>], [<a
>href=3D"#ref-SAX">SAX</a>], or similar processing as described in 7.2 =
>below. And, third,
>there is the possibility of coded character set conversion, such as =
>between UTF-8 and
>UTF-16, both of which all [<a href=3D"#ref-XML">XML</a>] compliant =
>processors are
>required to support.</p>
>
><p>Any canonicalization algorithm should yield output in a specific =
>fixed coded character
>set. For both the minimal canonicalization defined in this specification =
>and Canonical XML
>[<a href=3D"#ref-XML-C14N">XML-C14N</a>] that coded character set is =
>UTF-8 (without a byte
>order mark (BOM)).Neither the minimal canonicalization nor the Canonical =
>XML [<a
>href=3D"#ref-XML-C14N">XML-C14N</a>] algorithms provide character =
>normalization. We
>RECOMMEND that signature applications create XML content =
>(<u><code>Signature</code>
>elements and their descendents/content</u>) in Normalized Form C [<a =
>href=3D"#ref-NFC">NFC</a>]
>and check that any XML being consumed is in that form as well (if not, =
>signatures may
>consequently fail to validate). <u>Additionally</u>, none of these =
>algorithms provide data
>type normalization. Applications that normalize data types in varying =
>formats (e.g.,
>(true, false) or (1,0)) may not be able to validate each other's =
>signatures.</p>
>
><h3>7.1 <a id=3D"sec-XML-1" name=3D"sec-XML-1">XML 1.0</a>, Syntax =
>Constraints, and
>Canonicalization</h3>
>
><p>XML 1.0 [<a href=3D"#ref-XML">XML</a>] defines an interface where a =
>conformant
>application reading XML is given certain information from that XML and =
>not other
>information. In particular,=20
>
><ol>
> <li>line endings are normalized to the single character #xA by =
>dropping #xD characters if
> they are immediately followed by a #xA and replacing them with #xA =
>in all other cases,</li>
> <li>missing attributes declared to have default values are provided to =
>the application as if
> present with the default value, </li>
> <li>character references are replaced with the corresponding =
>character,</li>
> <li>entity references are replaced with the corresponding declared =
>entity,</li>
> <li>attribute values are normalized by <ol type=3D"A">
> <li>replacing character and entity references as above,</li>
> <li>replacing occurrences of #x9, #xA, and #xD with #x20 (space) =
>except that the sequence
> #xD#xA is replaced by a single space, and</li>
> <li>if the attribute is not declared to be CDATA, stripping all =
>leading and trailing spaces
> and replacing all interior runs of spaces with a single =
>space.</li>
> </ol>
> </li>
></ol>
>
><p><u>Note that items (2), (4), and (5C) depend on the presence of a =
>schema, DTD or
>similar declarations. The <code>Signature</code> element type is <a
>href=3D"http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#cvc-elt-lax">l=
>axly schema valid</a>
>[<a href=3D"#ref-XML-schema">XML-schema</a>], consequently external XML =
>or even XML within
>the same document as the signature may be (only) well formed or from =
>another namespace
>(where permitted by the signature schema); the noted items may not be =
>present. Thus, a
>signature with such content will only be verifiable by other signature =
>applications if the
>following syntax contraints are observed when generating any signed =
>material including the
><code>SignedInfo</code> element:</u>=20
>
><ol>
> <li>attributes having default values be explicitly present,</li>
> <li>all entity references (except "amp", "lt", =
>"gt",
> "apos", "quot", an<u>d other character entities =
>not representable in
> the encoding chosen</u>) be expanded,</li>
> <li>attribute value white space be normalized</li>
></ol>
>
><h3>7.2 <a id=3D"sec-DOM-SAX" name=3D"sec-DOM-SAX">DOM/SAX</a> =
>Processing and Canonicalization</h3>
>
><p>In addition to the canonicalization and syntax constraints discussed =
>above, many XML
>applications use the Document Object Model [<a =
>href=3D"#ref-DOM">DOM</a>] or The Simple API
>for XML [<a href=3D"#ref-SAX">SAX</a>]. DOM maps XML into a tree =
>structure of nodes
>and typically assumes it will be used on an entire document with =
>subsequent processing
>being done on this tree. SAX converts XML into a series of events such =
>as a start tag,
>content, etc. In either case, many surface characteristics such as the =
>ordering of
>attributes and insignificant white space within start/end tags is lost. =
>In addition,
>namespace declarations are mapped over the nodes to which they apply, =
>losing the namespace
>prefixes in the source text and, in most cases, losing where namespace =
>declarations
>appeared in the original instance.</p>
>
><p>If an XML Signature is to be produced or verified on a system using =
>the DOM or SAX
>processing, a canonical method is needed to serialize the relevant part =
>of a DOM tree or
>sequence of SAX events. XML canonicalization specifications, such as [<a
>href=3D"#ref-XML-C14N">XML-C14N</a>], are based only on information =
>which is preserved by
>DOM and SAX. For an XML Signature to be verifiable by an implementation =
>using DOM or SAX,
>not only must the syntax constraints given in <a =
>href=3D"#sec-XML-1">section 7.1</a> be
>followed but an appropriate XML canonicalization MUST be specified so =
>that the verifier
>can re-serialize DOM/SAX mediated input into the same octect stream that =
>was signed.</p>
>
><h2>8.0 <a id=3D"sec-Security" name=3D"sec-Security">Security =
>Considerations</a></h2>
>
><p>The XML Signature specification provides a very flexible digital =
>signature mechanism.
>Implementors must give consideration to their application threat models =
>and to the
>following factors.</p>
>
><h3>8.1 <a name=3D"sec-Security-Transofrms">Transforms</a></h3>
>
><p>A requirement of this specification is to permit signatures to =
>"apply to a
>part or totality of a XML document." (See section 3.1.3 of [<a
>href=3D"#ref-XML-Signature-RD">XML-Signature-RD</a>].) The =
><code>Transforms</code> mechanism
>meets this requirement by permitting one to sign data derived from =
>processing the content
>of the identified resource. For instance, applications that wish to sign =
>a form, but
>permit users to enter limited field data without invalidating a previous =
>signature on the
>form might use XPath [<a href=3D"#ref-XPath">XPath</a>] to exclude those =
>portions the user
>needs to change. <code>Transforms</code> may be arbitrarily specified =
>and may include
>encoding tranforms, canonicalization instructions or even XSLT =
>transformations. Three
>cautions are raised with respect to this feature in the following =
>sections.</p>
>
><p>Note, <a class=3D"link-def" href=3D"#def-ValidationCore">core =
>validation</a> behavior does
>not confirm that the signed data was obtained by applying each step of =
>the indicated
>transforms. (Though it does check that the digest of the resulting =
>content matches that
>specified in the signature.) For example, some application may be =
>satisfied with
>verifying an XML signature over a cached copy of already transformed =
>data. Other
>applications might require that content be freshly dereferenced and =
>transformed.</p>
>
><h4>8.1.1 <strong><a id=3D"sec-Secure" name=3D"sec-Secure">Only What is =
>Signed is Secure</a></strong></h4>
>
><p>First, obviously, signatures over a transformed document do not =
>secure any information
>discarded by transforms: only what is signed is secure.</p>
>
><p>Note that the use of Canonical XML [<a =
>href=3D"#ref-XML-C14N">XML-C14N</a>] ensures
>that all internal entities and XML namespaces are expanded within the =
>content being
>signed. All entities are replaced with their definitions and the =
>canonical form explicitly
>represents the namespace that an element would otherwise inherit. =
>Applications that do not
>canonicalize XML content (especially the <code>SignedInfo</code> =
>element) SHOULD NOT use
>internal entities and SHOULD represent the namespace explicitly within =
>the content being
>signed since they can not rely upon canonicalization to do this for =
>them.</p>
>
><h4>8.1.2 <a id=3D"sec-Seen" name=3D"sec-Seen">Only What is =
>"Seen" Should be Signed</a></h4>
>
><p>Additionally, the signature secures any information introduced by the =
>transform: only
>what is "seen" (that which is represented to the user via =
>visual, auditory or
>other media) should be signed. If signing is intended to convey the =
>judgment or consent of
>an automated mechanism or person, 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, such as the =
>screen images
>shown a user. However, this may result in data which is difficult for =
>subsequent software
>to manipulate. Instead, one can sign the data along with whatever =
>filters, style sheets,
>client profile or other information that affects its presentation.</p>
>
><h4>8.1.3 <a name=3D"sec-See">"See" What is Signed</a></h4>
>
><p class=3D"comment">Note: This new recommendation is actually a =
>combination/inverse of the
>earlier recommendations and is still under discussion.</p>
>
><p><u>Just as a person or automatable mechanism should only sign what it =
>"sees,"
>persons and automated mechanisms that trust the validity of a =
>transformed document on the
>basis of a valid signature SHOULD operate over the data that was =
>transformed (including
>canonicalization) and signed, not the original pre-transformed data. =
>This recommendation
>applies to transforms specified within the signature as well as those =
>included as part of
>the document itself. For instance, if an XML document includes an <a
>href=3D"http://www.w3.org/TR/xslt#section-Creating-Processing-Instruction=
>s">embedded
>stylesheet</a> [<a href=3D"#ref-XSLT">XSLT</a>] it is the transformed =
>document that that
>SHOULD be represented to the user and signed. To meet this =
>recommendation where a document
>references an external style sheet, the content of that external =
>resource SHOULD also be
>signed as via a signature <code>Reference</code> -- otherwise the =
>content of that external
>content might change which alters the resulting document without =
>invalidating the
>signature.</u></p>
>
><p>Some applications might operate over the original or intermediary =
>data but SHOULD be
>extremely careful about potential weaknesses introduced between the =
>original and
>transformed data. This is a trust decision about the character and =
>meaning of the
>transforms that an application needs to make with caution. Consider a =
>canonicalization
>algorithm that normalizes character case (lower to upper) or character =
>composition ('e and
>accent' to 'accented-e'). An adversary could introduce changes that are =
>normalized and
>consequently inconsequential to signature validity but material to a DOM =
>processor. For
>instance, by changing the case of a character one might influence the =
>result of an XPath
>selection. A serious risk is introduced if that change is normalized for =
>signature
>validation but the processor operates over the original data and returns =
>a different
>result than intended. Consequently, while we RECOMMEND all documents =
>operated upon and
>generated by signature applications be in [<a href=3D"#ref-NFC">NFC</a>] =
>(otherwise
>intermediate processors might unintentionally break the signature) =
>encoding normalizations
>SHOULD NOT be done as part of a signature transform, or (to state it =
>another way) if
>normalization does occur, the application SHOULD always "see" =
>(operate over) the
>normalized form.</p>
>
><h3>8.2 <a id=3D"sec-Check" name=3D"sec-Check">Check the Security =
>Model</a></h3>
>
><p>This standard specifies public key signatures and keyed hash =
>authentication codes.
>These have substantially different security models. Furthermore, it =
>permits user specified
>algorithms 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 private key can create =
>signatures. The number
>of holders of the private 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 private 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 different security =
>models. For
>example, methods involving biometrics usually depend on a physical =
>characteristic of the
>authorized user that can not be changed the way public or secret keys =
>can be and may have
>other security model differences.</p>
>
><h3>8.3 Algorithms, <a id=3D"sec-KeyLength" name=3D"sec-KeyLength">Key =
>Lengths</a>,
>Certificates, 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=3D"#ref-RANDOM">RANDOM</a>] and the size of the key, the security =
>of key and
>certificate authentication and distribution mechanisms, certificate =
>chain validation
>policy, protection of cryptographic processing from hostile observation =
>and tampering,
>etc.</p>
>
><p>Care must be exercised by validaters in executing the various =
>algorithms that may be
>specified in an XML signature and in the processing of any =
>"executable content"
>that might be provided to such algorithms as parameters, such as XSLT =
>transforms. The
>algorithms specified in this document will usually be implemented via a =
>trusted library
>but even there perverse parameters might cause unacceptable processing =
>or memory demand.
>Even more care may be warranted with application defined algorithms.</p>
>
><p>The security of an overall system will also depend on the security =
>and integrity of its
>operating procedures, its personnel, and on the administrative =
>enforcement of those
>procedures. All the factors listed in this section are important to the =
>overall security
>of a system; however, most are beyond the scope of this =
>specification.</p>
>
><h2>9.0 <a id=3D"sec-Schema" name=3D"sec-Schema">Schema</a>, DTD, Data =
>Model, and Valid
>Examples</h2>
>
><dl>
> <dt>XML Signature Schema Instance</dt>
> <dd><a =
>href=3D"xmldsig-core-schema.xsd">xmldsig-core-schema.xsd</a></dd>
> <dd>Valid XML schema instance based on the Last Call 20000407 =
>Schema/DTD [<a
> href=3D"#ref-XML-schema">XML-Schema</a>].</dd>
> <dt>XML Signature DTD</dt>
> <dd><a =
>href=3D"xmldsig-core-schema.dtd">xmldsig-core-schema.dtd</a></dd>
> <dt>RDF Data Model</dt>
> <dd><a =
>href=3D"xmldsig-datamodel-20000112.gif">xmldsig-datamodel-20000112.gif</a=
>></dd>
> <dt>XML Signature Object Example</dt>
> <dd><a href=3D"signature-example.xml">signature-example.xml</a></dd>
> <dd>A cryptographical invalid XML example that includes foreign =
>content and validates under
> the schema. (It validates under the DTD when the foreign content is =
>removed or the DTD is
> modified accordingly).</dd>
> <dt>XML RSA Signature Valid Example</dt>
> <dd><a =
>href=3D"signature-example-rsa.xml">signature-example-rsa.xml</a></dd>
> <dd>An XML Signature example by Kent Tamura with generated =
>cryptographic values, uses <a
> =
>href=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000613">WD-xml-c14n-20000=
>613</a>, that has
> been confirmed by Petteri Stenius.</dd>
> <dt>XML DSA Signature Valid Example</dt>
> <dd><a =
>href=3D"signature-example-dsa.xml">signature-example-dsa.xml</a></dd>
> <dd>Similar to above but uses DSA.</dd>
></dl>
>
><h2>10.0 <a id=3D"sec-Definitions" =
>name=3D"sec-Definitions">Definitions</a></h2>
>
><dl>
> <dt><a id=3D"def-AuthenticationCode" =
>name=3D"def-AuthenticationCode">Authentication Code</a></dt>
> <dd>A value generated from the application of a shared key to a =
>message via a cryptographic
> algorithm such that it has the properties of <a =
>href=3D"#def-AuthenticationMessage"
> class=3D"link-def">message authentication</a> (<a =
>href=3D"#def-Integrity" class=3D"link-def">integrity</a>)
> but not <a href=3D"#def-AuthenticationSigner" =
>class=3D"link-def">signer authentication</a></dd>
> <dt><a id=3D"def-AuthenticationMessage" =
>name=3D"def-AuthenticationMessage">Authentication,
> Message</a></dt>
> <dd>"A signature should identify what is signed, making it =
>impracticable to falsify or
> alter either the signed matter or the signature without =
>detection." [<a
> href=3D"http://www.abanet.org/scitech/ec/isc/dsgfree.html">Digital =
>Signature Guidelines</a>,
> <a href=3D"#ref-ABA">ABA</a>]</dd>
> <dt><a id=3D"def-AuthenticationSigner" =
>name=3D"def-AuthenticationSigner">Authentication, Signer</a></dt>
> <dd>"A signature should indicate who signed a document, message =
>or record, and should
> be difficult for another person to produce without =
>authorization." [<a
> href=3D"http://www.abanet.org/scitech/ec/isc/dsgfree.html">Digital =
>Signature Guidelines</a>,
> <a href=3D"#ref-ABA">ABA</a>]</dd>
> <dt><a id=3D"def-Core" name=3D"def-Core">Core</a></dt>
> <dd>The syntax and processing defined by this specification, including =
><a
> href=3D"#def-ValidationCore" class=3D"link-def">core validation</a>. =
>We use this term to
> distinguish other markup, processing, and applications semantics =
>from our own.</dd>
> <dt><a id=3D"def-DataObject" name=3D"def-DataObject">Data Object</a> =
>(Content/Document)</dt>
> <dd>The actual binary/octet data being operated on (transformed, =
>digested, or signed) by an
> application -- frequently an <a
> =
>href=3D"http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7">HTTP =
>entity</a> [<a
> href=3D"#ref-HTTP">HTTP</a>]. Note that the proper noun =
><code>Object</code> designates a
> specific XML element. Occasionally we refer to a data object as a =
><em>document</em> or as
> a <em><a href=3D"#def-Resource" class=3D"link-def">resource</a>'s =
>content</em>. The term <em>element
> content</em> is used to describe the data between XML start and end =
>tags [<a
> href=3D"#ref-XML">XML</a>]. The term <em>XML document</em> is used =
>to describe data objects
> which conform to the XML specification [<a =
>href=3D"#ref-XML">XML</a>].</dd>
> <dt><a id=3D"def-Integrity" name=3D"def-Integrity">Integrity</a></dt>
> <dd>The inability to change a message without also changing the =
>signature value. See <a
> href=3D"#def-AuthenticationMessage" class=3D"link-def">message =
>authentication</a>.</dd>
> <dt><a id=3D"def-Object" name=3D"def-Object">Object</a></dt>
> <dd>An XML Signature element wherein arbitrary (non-<a =
>href=3D"#def-Core" class=3D"link-def">core</a>)
> data may be placed. An <code>Object</code> element is merely one =
>type of digital data (or
> document) that can be signed via a <code>Reference</code>.</dd>
> <dt><a id=3D"def-Resource" name=3D"def-Resource">Resource</a></dt>
> <dd>"A resource can be anything that has identity. Familiar =
>examples include an
> electronic document, an image, a service (e.g., 'today's weather =
>report for Los Angeles'),
> and a collection of other resources.... The resource is the =
>conceptual mapping to an
> entity or set of entities, not necessarily the entity which =
>corresponds to that mapping at
> any particular instance in time. Thus, a resource can remain =
>constant even when its
> content---the entities to which it currently corresponds---changes =
>over time, provided
> that the conceptual mapping is not changed in the process." [<a =
>href=3D"#ref-URI">URI</a>]
> In order to avoid a collision of the term <em>entity</em> within the =
>URI and XML
> specifications, we use the term <em>data object</em>, =
><em>content</em> or <em>document</em>
> to refer to the actual bits being operated upon.</dd>
> <dt><a id=3D"def-Signature" name=3D"def-Signature">Signature</a></dt>
> <dd>Formally speaking, a value generated from the application of a =
>private key to a message
> via a cryptographic algorithm such that it has the properties of <a
> href=3D"#def-AuthenticationSigner" class=3D"link-def">signer =
>authentication</a> and <a
> href=3D"#def-AuthenticationMessage" class=3D"link-def">message =
>authentication</a> (<a
> href=3D"#def-Integrity" class=3D"link-def">integrity</a>). (However, =
>we sometimes use the term
> signature generically such that it encompasses <a =
>href=3D"#def-AuthenticationCode"
> class=3D"link-def">Authentication Code</a> values as well, but we =
>are careful to make the
> distinction when the property of <a =
>href=3D"#def-AuthenticationSigner" class=3D"link-def">signer
> authentication</a> is relevant to the exposition.) A signature may =
>be (non-exclusively)
> described as <a href=3D"#def-SignatureDetached" =
>class=3D"link-def">detached</a>, <a
> href=3D"#def-SignatureEnveloping" class=3D"link-def">enveloping</a>, =
>or <a
> href=3D"#def-SignatureEnveloped" =
>class=3D"link-def">enveloped</a>.</dd>
> <dt><u><a name=3D"def-SignatureApplication">Signature, =
>Application</a></u></dt>
> <dd><u>An application that implements the MANDATORY (REQUIRED/MUST) =
>portions of this
> specification; these conformance requirements are over the structure =
>of the <code>Signature</code>
> element type and its child's content <code>SignatureValue</code> and =
>mandatory to support
> algorithms.</u></dd>
> <dt><a id=3D"def-SignatureDetached" =
>name=3D"def-SignatureDetached">Signature, Detached</a></dt>
> <dd>The signature is over content external to the =
><code>Signature</code> element, and can be
> identified via a <code>URI</code> or transform. Consequently, the =
>signature is
> "detached" from the content it signs. This definition =
>typically applies to
> separate data objects, but it also includes the instance where the =
><code>Signature</code>
> and data object reside within the same XML document but are sibling =
>elements.</dd>
> <dt><a id=3D"def-SignatureEnveloping" =
>name=3D"def-SignatureEnveloping">Signature, Enveloping</a></dt>
> <dd>The signature is over content found within an <code>Object</code> =
>element of the
> signature itself. The <code>Object</code>(or its content) is =
>identified via a <code>Reference</code>
> (via a <code>URI</code> fragment idenitifier or transform).</dd>
> <dt><a id=3D"def-SignatureEnveloped" =
>name=3D"def-SignatureEnveloped">Signature, Enveloped</a></dt>
> <dd>The signature is over the XML content that contains the signature =
>as an element. The
> content provides the root XML document element. Obviously, enveloped =
>signatures must take
> care not to include their own value in the calculation of the =
><code>SignatureValue</code>.</dd>
> <dt><a id=3D"def-Transform" name=3D"def-Transform">Transform</a></dt>
> <dd>The processing of a octet stream from source content to derived =
>content. Typical
> transforms include XML Canonicalization, XPath, and XSLT.</dd>
> <dt><a id=3D"def-ValidationCore" =
>name=3D"def-ValidationCore">Validation, Core</a></dt>
> <dd>The core processing requirements of this specification requiring =
><a
> href=3D"#def-ValidationSignature" class=3D"link-def">signature =
>validation</a> and <code>SignedInfo</code>
> <a href=3D"#def-ValidationReference" class=3D"link-def">reference =
>validation</a>.</dd>
> <dt><a id=3D"def-ValidationReference" =
>name=3D"def-ValidationReference">Validation, Reference</a></dt>
> <dd>The hash value of the identified and transformed content, =
>specified by <code>Reference</code>,
> matches its specified <code>DigestValue</code>.</dd>
> <dt><a id=3D"def-ValidationSignature" =
>name=3D"def-ValidationSignature">Validation, Signature</a></dt>
> <dd>The <code>SignatureValue</code> matches the result of processing =
><code>SignedInfo</code>
> with <code>CanonicalizationMethod</code> and =
><code>SignatureMethod</code> as
> specified in section 3.2.</dd>
> <dt><a id=3D"def-ValidationTrustApplication" =
>name=3D"def-ValidationTrustApplication">Validation,
> Trust/Application</a></dt>
> <dd>The application determines that the semantics associated with a =
>signature are valid. For
> example, an application may validate the time stamps or the =
>integrity of the signer key --
> though this behavior is external to this <a =
>href=3D"#def-ValidationCore" class=3D"link-def">core</a>
> specification.</dd>
></dl>
>
><h2>11.0 <a id=3D"sec-References" =
>name=3D"sec-References">References</a></h2>
>
><dl>
> <dt><a id=3D"ref-ABA" name=3D"ref-ABA">ABA</a></dt>
> <dd><a =
>href=3D"http://www.abanet.org/scitech/ec/isc/dsgfree.html">Digital =
>Signature
> Guidelines.</a><br />
> <a =
>href=3D"http://www.abanet.org/scitech/ec/isc/dsgfree.html">http://www.aba=
>net.org/scitech/ec/isc/dsgfree.html</a></dd>
> <dt><a id=3D"ref-Bourret" name=3D"ref-Bourret">Bourret</a></dt>
> <dd><a =
>href=3D"http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/xmld=
>td.html">Declaring
> Elements and Attributes in an XML DTD.</a> Ron Bourret.<br />
> <a =
>href=3D"http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/xmld=
>td.html">http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/xml=
>dtd.html</a></dd>
> <dt><a id=3D"ref-DOM" name=3D"ref-DOM">DOM</a></dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/">Document =
>Object Model
> (DOM) Level 1 Specification.</a> W3C Recommendation. V. Apparao, S. =
>Byrne, M. Champion, S.
> Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. =
>Wilson, L. Wood. October
> 1998.<br />
> <a =
>href=3D"http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/">http://www.w=
>3.org/TR/1998/REC-DOM-Level-1-19981001/</a></dd>
> <dt><strike><a id=3D"ref-DOMHASH" =
>name=3D"ref-DOMHASH">DOMHASH</a></strike></dt>
> <dd><strike><u><a href=3D"http://www.ietf.org/rfc/rfc2803.txt">RFC =
>2803.</a> <a
> href=3D"http://www.ietf.org/rfc/rfc2803.txt"><i>Digest Values for =
>DOM (DOMHASH).</i></a> H.
> Maruyama, K. Tamura, N. Uramoto. April 2000</u></strike></dd>
> <dt><a id=3D"ref-DSS" name=3D"ref-DSS">DSS</a></dt>
> <dd><a href=3D"http://csrc.nist.gov/fips/fips1861.pdf">FIPS PUB =
>186-1</a>. <i>Digital
> Signature Standard (DSS).</i> U.S. Department of Commerce/National =
>Institute of Standards
> and Technology.<br />
> <a =
>href=3D"http://csrc.nist.gov/fips/fips1861.pdf">http://csrc.nist.gov/fips=
>/fips1861.pdf</a></dd>
> <dt><a id=3D"ref-HMAC" name=3D"ref-HMAC">HMAC</a></dt>
> <dd><a href=3D"ftp://ftp.isi.edu/in-notes/rfc2104.txt">RFC 2104</a>. =
><i>HMAC: Keyed-Hashing
> for Message Authentication.</i> H. Krawczyk, M. Bellare, R. Canetti. =
>February 1997.</dd>
> <dt><a id=3D"ref-HTTP" name=3D"ref-HTTP">HTTP</a></dt>
> <dd><a href=3D"http://www.w3.org/Protocols/rfc2616/rfc2616.html">RFC =
>2616</a>. <i>Hypertext
> Transfer Protocol -- HTTP/1.1</i>. J. Gettys, J. Mogul, H. Frystyk, =
>L. Masinter, P. Leach,
> T. Berners-Lee. June 1999.</dd>
> <dt><a id=3D"ref-KEYWORDS" name=3D"ref-KEYWORDS">KEYWORDS</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a> <i>Key =
>words for use in RFCs
> to Indicate Requirement Levels.</i> S. Bradner. March 1997.</dd>
> <dt><u><a href=3D"#ref-LDAP-DN" =
>name=3D"ref-LDAP-DN">LDAP-DN</a></u></dt>
> <dd><u><a =
>href=3D"http://www.ietf.org/rfc/rfc2253.txt">RFC2253</a>.<em> =
>Lightweight Directory
> Access Protocol (v3): UTF-8 String Representation of Distinguished =
>Names. </em>M. Wahl, S.
> Kille, T. Howes. December 1997.</u></dd>
> <dt><a id=3D"ref-MD5" name=3D"ref-MD5">MD5</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc1321.txt">RFC 1321</a>. =
><i>The MD5 Message-Digest
> Algorithm.</i> R. Rivest. April 1992.</dd>
> <dt><a id=3D"ref-MIME" name=3D"ref-MIME">MIME</a></dt>
> <dd><a href=3D"ftp://ftp.isi.edu/in-notes/rfc2045.txt">RFC 2045</a>. =
><i>Multipurpose Internet
> Mail Extensions (MIME) Part One: Format of Internet Message =
>Bodies</i>. N. Freed & N.
> Borenstein. November 1996.</dd>
> <dt><a id=3D"ref-NFC" name=3D"ref-NFC">NFC</a></dt>
> <dd><a =
>href=3D"http://www.unicode.org/unicode/reports/tr15/tr15-18.html">TR15</a=
>>. <em>Unicode
> Normalization Forms.</em> M. Davis, M. D=FCrst. Revision 18: =
>November 1999.</dd>
> <dt><a id=3D"ref-PGP" name=3D"ref-PGP">PGP</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc2440.txt">RFC 2440</a> =
><i>OpenPGP Message Format.</i>
> J. Callas, L. Donnerhacke, H. Finney, R. Thayer. November 1998.</dd>
> <dt><a id=3D"ref-RANDOM" name=3D"ref-RANDOM">RANDOM</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc1750.txt">RFC1750</a> =
><i>Randomness Recommendations
> for Security.</i> D. Eastlake, S. Crocker, J. Schiller. December =
>1994.</dd>
> <dt><a id=3D"ref-RDF" name=3D"ref-RDF">RDF</a></dt>
> <dd><a href=3D"http://www.w3.org/TR/2000/CR-rdf-schema-20000327/">RDF =
>Schema</a> W3C Candidate
> Recommendation. D. Brickley, R.V. Guha. March 2000.<br />
> <a =
>href=3D"http://www.w3.org/TR/2000/CR-rdf-schema-20000327/">http://www.w3.=
>org/TR/2000/CR-rdf-schema-20000327/</a></dd>
> <dd><a href=3D"http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">RDF =
>Model and Syntax</a>
> W3C Recommendation. O. Lassila, R. Swick. February 1999.<br />
> <a =
>href=3D"http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">http://www.w3=
>.org/TR/1999/REC-rdf-syntax-19990222/</a></dd>
> <dt><a id=3D"URI" name=3D"URI"></a><a id=3D"ref-P1363" =
>name=3D"ref-P1363">P1363</a></dt>
> <dd>IEEE P1363: Standard Specifications for Public Key =
>Cryptography.</dd>
> <dt><a id=3D"ref-PKCS1" name=3D"ref-PKCS1">PKCS1</a></dt>
> <dd><a href=3D"ftp://ftp.isi.edu/in-notes/rfc2437.txt">RFC 2437</a>. =
><i>PKCS #1: RSA
> Cryptography Specifications Version 2.0.</i> B. Kaliski, J. Staddon. =
>October 1998.</dd>
> <dt><a id=3D"ref-SAX" name=3D"ref-SAX">SAX</a></dt>
> <dd><a href=3D"http://www.megginson.com/SAX/index.html">SAX: The =
>Simple API for XML</a> David
> Megginson et. al. May 1998.<br />
> <a =
>href=3D"http://www.megginson.com/SAX/index.html">http://www.megginson.com=
>/SAX/index.html</a></dd>
> <dt><a id=3D"ref-SHA-1" name=3D"ref-SHA-1">SHA-1</a></dt>
> <dd><a href=3D"http://csrc.nist.gov/fips/fip180-1.pdf">FIPS PUB =
>180-1</a>. <i>Secure Hash
> Standard.</i> U.S. Department of Commerce/National Institute of =
>Standards and Technology.<br
> />
> <a =
>href=3D"http://csrc.nist.gov/fips/fip180-1.pdf">http://csrc.nist.gov/fips=
>/fip180-1.pdf</a></dd>
> <dt class=3D"label"><u><a name=3D"unicode">Unicode</a></u> </dt>
> <dd>The Unicode Consortium. <cite>The Unicode Standard.</cite> <br>
> <a =
>href=3D"http://www.unicode.org/unicode/standard/standard.html">http://www=
>.unicode.org/unicode/standard/standard.html</a></dd>
> <dt><a name=3D"ref-UTF-16">UTF-16</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc2781.txt">RFC2781</a>. =
><em>UTF-16, an encoding of
> ISO 10646.</em> P. Hoffman , F. Yergeau. February 2000.</dd>
> <dt><a id=3D"ref-UTF-8" name=3D"ref-UTF-8">UTF-8</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc2279.txt">RFC2279</a>. =
><i>UTF-8, a transformation
> format of ISO 10646</i>. F. Yergeau. Janaury 1998.</dd>
> <dt><a id=3D"ref-URI" name=3D"ref-URI">URI</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc2396.txt">RFC2396</a>. =
><i>Uniform Resource
> Identifiers (URI): Generic Syntax.</i> T. Berners-Lee, R. Fielding, =
>L. Masinter. August
> 1998</dd>
> <dt class=3D"label"><u><a =
>name=3D"ref-URI-Literal">URI-Literal</a></u></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc2732.txt">RFC 2732</a>. =
><em>Format for Literal IPv6
> Addresses in URL's</em>. R. Hinden, B. Carpenter, L. Masinter. =
>December 1999.</dd>
> <dt><a id=3D"ref-URL" name=3D"ref-URL">URL</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc1738.txt">RFC1738.</a> =
><i>Uniform Resource Locators
> (URL).</i> Berners-Lee, T., Masinter, L., and M. McCahill. December =
>1994.</dd>
> <dt><a id=3D"ref-URN" name=3D"ref-URN">URN</a></dt>
> <dd><a href=3D"ftp://ftp.isi.edu/in-notes/rfc2141.txt">RFC 2141</a>. =
><i>URN Syntax.</i> R.
> Moats. May 1997.</dd>
> <dd><a href=3D"ftp://ftp.isi.edu/in-notes/rfc2611.txt">RFC 2611</a>. =
><i>URN Namespace
> Definition Mechanisms.</i> L. Daigle, D. van Gulik, R. Iannella, P. =
>Falstrom. June 1999.</dd>
><u john=3D"john">
> <dt><a id=3D"ref-XHTML" name=3D"ref-XHTML">XHTML 1.0</a></dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/REC-xhtml1-20000126/">XHTML(tm) 1.0: =
>The Extensible Hypertext Markup Language</a>=20
> Recommendation. S. Pemberton, D. Raggett, et. al. January 2000.<br />
> <a =
>href=3D"http://www.w3.org/TR/2000/REC-xhtml1-20000126/">http://www.w3.org=
>/TR/2000/REC-xhtml1-20000126/</a></dd>
></u>
> <dt><a id=3D"ref-XLink" name=3D"ref-XLink">XLink</a></dt>
> <dd><a href=3D"http://www.w3.org/1999/07/WD-xlink-19990726">XML =
>Linking Language.</a>Working
> Draft. S. DeRose, D. Orchard, B. Trafford. July 1999.<br />
> <a =
>href=3D"http://www.w3.org/1999/07/WD-xlink-19990726">http://www.w3.org/19=
>99/07/WD-xlink-19990726</a></dd>
> <dt><a id=3D"XML" name=3D"XML"></a><a id=3D"ref-XML" =
>name=3D"ref-XML">XML</a></dt>
> <dd><a href=3D"http://www.w3.org/TR/1998/REC-xml-19980210">Extensible =
>Markup Language (XML)
> 1.0</a> Recommendation. T. Bray, J. Paoli, C. M. Sperberg-McQueen. =
>February 1998.</dd>
> <dd><a =
>href=3D"http://www.w3.org/TR/1998/REC-xml-19980210">http://www.w3.org/TR/=
>1998/REC-xml-19980210</a></dd>
> <dt><a id=3D"ref-XML-C14N" name=3D"ref-XML-C14N">XML-C14N</a></dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710">Canonical =
>XML.</a> Working
> Draft. J. Boyer. July 2000.</dd>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xml-c14n-20000710.html">http://www.w=
>3.org/TR/2000/WD-xml-c14n-20000710</a></dd>
> <dt><a name=3D"ref-XML-Japanese">XML-Japanese</a></dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/">XML =
>Japanese Profile</a>.
> W3C NOTE. <span class=3D"author">M. <span =
>class=3D"name">MURATA</span></span> April 2000 <a
> class=3D"loc" =
>href=3D"http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/">http://www=
>.w3.org/TR/2000/NOTE-japanese-xml-20000414/</a></dd>
> <dt><a name=3D"ref-XML-MT">XML-MT</a></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc2376.txt">RFC 2376</a>. =
><em>XML Media Types</em>. E.
> Whitehead, M. Murata. July 1998.</dd>
> <dt><a id=3D"ref-XML-ns" name=3D"ref-XML-ns">XML-ns</a></dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/1999/REC-xml-names-19990114/">Namespaces in =
>XML</a>
> Recommendation. T. Bray, D. Hollander, A. Layman. Janaury 1999.</dd>
> <dd><a =
>href=3D"http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.=
>org/TR/1999/REC-xml-names-19990114</a></dd>
> <dt><a id=3D"XML-schema" name=3D"XML-schema"></a><a =
>id=3D"ref-XML-schema" name=3D"ref-XML-schema">XML-schema</a></dt>
> <dd><a href=3D"http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/">XML =
>Schema Part 1:
> Structures</a> Working Draft. D. Beech, M. Maloney, N. Mendelshohn. =
>April 2000.</dd>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/">http://www.w3=
>.org/TR/2000/WD-xmlschema-1-20000407/</a><br
> />
> <a href=3D"http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/">XML =
>Schema Part 2: Datatypes</a>
> Working Draft. P. Biron, A. Malhotra. April 2000.</dd>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/">http://www.w3=
>.org/TR/2000/WD-xmlschema-2-20000407/</a></dd>
> <dt><a id=3D"XML-Signature-RD" name=3D"XML-Signature-RD"></a><u><a =
>id=3D"ref-XML-Signature-RD"
> name=3D"ref-XML-Signature-RD">XML-Signature-RD</a></u></dt>
> <dd><a href=3D"http://www.ietf.org/rfc/rfc2807.txt">RFC 2807</a>. <a
> href=3D"http://www.w3.org/TR/xmldsig-requirements">XML Signature =
>Requirements.</a> J.
> Reagle, April 2000.<br />
> <a =
>href=3D"http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014.html">=
>http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014</a></dd>
> <dt><u><a id=3D"ref-XPath" name=3D"ref-XPath">XPath</a></u></dt>
> <dd><a href=3D"ttp://www.w3.org/TR/1999/REC-xpath-19991116">XML Path =
>Language (XPath)Version
> 1.0</a>. Recommendation. J. Clark, S. DeRose. October 1999.<br>
> <a =
>href=3D"http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/T=
>R/1999/REC-xpath-19991116</a></dd>
> <dt><u><a id=3D"ref-XPointer" =
>name=3D"ref-XPointer">XPointer</a></u></dt>
> <dd><a href=3D"http://www.w3.org/TR/2000/CR-xptr-20000607">XML Pointer =
>Language (XPointer)</a>.
> Candidate Recommendation. S. DeRose, R. Daniel, E. Maler.</dd>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/CR-xptr-20000607">http://www.w3.org/TR/=
>2000/CR-xptr-20000607</a></dd>
> <dt><a id=3D"ref-XSL" name=3D"ref-XSL">XSL</a></dt>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xsl-20000327/xslspec.html">Extensibl=
>e Stylesheet
> Language (XSL)</a> Working Draft. S. Adler, A. Berglund, J. Caruso, =
>S. Deach, P. Grosso,
> E. Gutentag, A. Milowski, S. Parnell, J. Richman, S. Zilles. March =
>2000.</dd>
> <dd><a =
>href=3D"http://www.w3.org/TR/2000/WD-xsl-20000327/xslspec.html">http://ww=
>w.w3.org/TR/2000/WD-xsl-20000327/xslspec.html</a></dd>
> <dt><a id=3D"ref-XSLT" name=3D"ref-XSLT">XSLT</a></dt>
> <dd><a href=3D"http://www.w3.org/TR/1999/REC-xslt-19991116.html">XSL =
>Transforms (XSLT) Version
> 1.0</a>. Recommendation. J. Clark. November 1999.</dd>
> <dd><a =
>href=3D"http://www.w3.org/TR/1999/REC-xslt-19991116.html">http://www.w3.o=
>rg/TR/1999/REC-xslt-19991116.html</a></dd>
> <dt><strike><u><a id=3D"ref-WebData" =
>name=3D"ref-WebData">WebData</a></u></strike></dt>
> <dd><strike><a href=3D"http://www.w3.org/1999/06/07-WebData">Web =
>Architecture: Describing and
> Exchanging Data.</a> W3C Note. T. Berners-Lee, D. Connolly, R. =
>Swick. June 1999.</strike></dd>
> <dd><strike><a =
>href=3D"http://www.w3.org/1999/06/07-WebData">http://www.w3.org/1999/06/0=
>7-WebData</a></strike></dd>
></dl>
>
><h2>12. <a id=3D"sec-Authors" name=3D"sec-Authors">Authors'</a> =
>Address</h2>
>
><p>Donald E. Eastlake 3rd<br />
>Motorola, Mail Stop: M4-10<br />
>20 Forbes Boulevard<br />
>Mansfield, MA 02048 USA<br />
>Phone: 1-508-261-5434<br />
>Email: <a =
>href=3D"mailto:Donald.Eastlake@motorola.com">Donald.Eastlake@motorola.com=
></a></p>
>
><p>Joseph M. Reagle Jr., <a href=3D"http://www.w3.org/">W3C</a><br />
>Massachusetts Institute of Technology<br />
>Laboratory for Computer Science<br />
>NE43-350, 545 Technology Square<br />
>Cambridge, MA 02139<br />
>Phone: + 1.617.258.7621<br />
>Email: <a href=3D"mailto:reagle@w3.org">reagle@w3.org</a></p>
>
><p>David Solo<br />
>Citigroup<br />
>666 Fifth Ave, 3rd Floor<br />
>NY, NY 10103 USA<br />
>Phone: +1-212-830-8118<br />
>Email: <a href=3D"mailto:dsolo@alum.mit.edu">dsolo@alum.mit.edu</a></p>
></body>
></html>
>
>------=_NextPart_000_003E_01C00C3C.6DC37130--
>
Received on Tuesday, 29 August 2000 08:41:11 UTC