W3C home > Mailing lists > Public > public-xmlsec@w3.org > January 2010

Re: RNG schema plans

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 19 Jan 2010 08:09:09 -0500
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, XMLSec WG Public List <public-xmlsec@w3.org>
Message-Id: <85E03978-690D-4F1B-91BB-7A20361DA670@nokia.com>
To: ext MURATA Makoto (FAMILY Given) <eb2m-mrt@asahi-net.or.jp>
Please review the message from Makoto. It should address the concern  
with xslt URI reference, ISSUE-176, and also asks for confirmation  
regarding assumptions (only spec and XSD knowledge needed to answer)

ISSUE-177 can now be closed (validation of sp-example.xml with  
properties RNC schema) since it now validates.
ISSUE-175 can be closed since we now have driver schema for signature  
properties and I've updated the draft to reference it (tested)

regards, Frederick

Frederick Hirsch
Nokia



On Jan 19, 2010, at 7:13 AM, ext MURATA Makoto (FAMILY Given) wrote:

>> I received a revision of the XML Signature 1.1 RNG schema from Makoto
>> (Thanks!) and was able to validate sp-example.xml against it.
>
> I fixed another bug in my schemas.
> Now, signature-enveloped-dsa.xml, signature-enveloping-hmac- 
> sha1-40.xml
> signature-enveloping-b64-dsa.xml, signature-enveloping-dsa.xml,
> signature-enveloping-hmac-sha1.xml, signature-enveloping-rsa.xml,
> signature-external-b64-dsa.xml, and signature-external-dsa.xml  
> validate.
>
>> I'm not sure why we have the URI for xslt defined in the xmldsig- 
>> core-
>> schema.rnc, but I think it is to indicate that this is one of the
>> allowed transforms. Is this correct Makoto? Is there any harm in
>> having this xslt URI included?
>
> Depending on the value of @Algorithm, different content models are  
> used.
>
>> ds_TransformType =
>>  ds_CanonicalizationMethodType
>>  | attribute Algorithm {
>>      xsd:anyURI "http://www.w3.org/2000/09/xmldsig#base64" }
>>  | (attribute Algorithm {
>>       xsd:anyURI "http://www.w3.org/TR/1999/REC-xpath-19991116"},
>>    element XPath { xsd:string })
>>  | attribute Algorithm {
>>       xsd:anyURI "http://www.w3.org/2000/09/xmldsig#enveloped-signature 
>> "}
>>  | (attribute Algorithm {
>>       xsd:anyURI "http://www.w3.org/TR/1999/REC-xslt-19991116"},
>>    ds_Xslt)
>
> When the attribute value is ...#base64 or ...#enveloped-signature,
> children are not allowed (this is my understanding of the spec).    
> When
> it is ...REC-xpath-19991116, an XPath element is allowed and nothing  
> else
> is allowed (again, this is my understanding of the spec).  When it is
> ...REC-xslt-19991116, an XSLT stylesheet is allowed.  I would argue  
> that
> such tight constraints are useful for validation and also improve the
> quality of the spec.
>
> Furthermore, allowAnyForeign.rnc, which is included by
> any-containing-xmldsig.rnc,
> further allows every attribute value and any sequence of foreign  
> elements.
> (Again, this is my understanding of the specification.)
>
>> ds_SignatureMethodType |=
>>  attribute Algorithm { xsd:anyURI },
>>  anyForeignElement*
>
> Cheers,
> Makoto
>
>
Received on Tuesday, 19 January 2010 13:09:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 January 2010 13:09:48 GMT