- From: Scott Cantor <cantor.2@osu.edu>
- Date: Mon, 25 Jan 2010 11:19:04 -0500
- To: "'MURATA Makoto \(FAMILY Given\)'" <eb2m-mrt@asahi-net.or.jp>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>
MURATA Makoto (FAMILY Given) wrote on 2010-01-25: > Why isn't processContents="lax" specified for <xsd:any> within the dcl > of CanonicalizationMethodType and that of SignatureMethodType? That's a good question. It may be a bug, or it may be a deliberate choice from years ago that might have considered some of the open content models more "security sensitive" than others. We'll have to bring it up on the call tomorrow. There are a few "old timers" left around that might remember. > Why > > <sequence> > > rather than > > <choice> I think the answer is that if choice was used, it would prevent HMACOutputLength from being used along with an extension element, and nothing precludes that if an algorithm chose to do that. > in the definition of SignatureMethodType? Even when > Algorithm = "http://www.w3.org/2000/09/xmldsig#hmac-sha1", > are foreign elements intentionally allowed to follow > the HMACOutputLength element? No, because that algorithm already defines what's permitted. > Or, as in the other cases, > the prose wins here and the <any> is ignored when > Algorithm = "http://www.w3.org/2000/09/xmldsig#hmac-sha1"? Yes, it's superseded by the algorithm's specified content. > Even when @Algorithm != "http://www.w3.org/2000/09/xmldsig#hmac-sha1", > can a SignatureMethod element have an HMACOutputLength element > as a child? Yes. This is like the XPath case inside Transform. Not likely, but not invalid. -- Scott
Received on Monday, 25 January 2010 16:19:36 UTC