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

Re: Proposed Resolution for "Confusing schema fragment in Encryption 1.1"

From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: Wed, 18 Jan 2012 13:23:30 +0900
Message-ID: <CALvn5EAnH=TDDNAF4BmgX50sXs3oLBUu_9kGFVzb9=U44YVbSA@mail.gmail.com>
To: public-xmlsec@w3.org
Frederick,

Your rewrite looks good to me.

Regards,
Makoto

2012/1/17  <Frederick.Hirsch@nokia.com>:
> Makoto
>
> I've entered your concern about the clarity regarding schema in the XML
> Encryption 1.1 Last Call for the MGF addition as Last Call comment
> LC-2581, https://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmlenc-core1-20120105/2581
>
> To address this concern,  I've updated the  XML Encryption 1.1 editor's
> draft RSA-OAEP section
> 5.5.2, http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html#sec-RSA-OAEP
>
> to contain the following:
>
> [[
>
> The XML Encryption 1.0 schema definition and description for
> the EncryptionMethod element is in section 3.2 The EncryptionMethod Element.
> The following shows the XML Encryption 1.1 addition for the MGF type:
>
> Schema Definition:
>
>     <element name="MGF" type="xenc11:MGFType"/>
>     <complexType name="MGFType">
>       <complexContent>
>         <restriction base="xenc11:AlgorithmIdentifierType">
>           <attribute name="Algorithm" type="anyURI" use="required" />
>         </restriction>
>       </complexContent>
>     </complexType>
>
>
> ]]
>
> instead of the original that was less clear:
>
> [[
>
> Schema Definition:
>     <!-- use these element types as children of EncryptionMethod
>       when used with RSA-OAEP -->
>     <element name="OAEPparams" minOccurs="0" type="base64Binary"/>
>     <element ref="ds:DigestMethod" minOccurs="0"/>
>     <element name="MGF" type="xenc11:MGFType"/>
>     <complexType name="MGFType">
>       <complexContent>
>         <restriction base="xenc11:AlgorithmIdentifierType">
>           <attribute name="Algorithm" type="anyURI" use="required" />
>         </restriction>
>       </complexContent>
>     </complexType>
>
> ]]
>
> Makoto, Scott: Does this resolve the issue?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Jan 16, 2012, at 1:50 PM, ext Cantor, Scott wrote:
>
> On 1/16/12 10:58 AM, "Frederick.Hirsch@nokia.com"
> <Frederick.Hirsch@nokia.com> wrote:
>
>
> Is this what you are saying?
>
>
> No, see below.
>
> I don't think there is a problem with the xenc 1.1 schema file itself, as
>
> MGF is defined as a stand-alone type in the xenc11 namespace.  Do you see
>
> a problem with the 1.1 schema file (attached)?
>
>
> No, I think the issue is with the way the fragment is laid out inside the
> spec.
>
> The document also highlights the schema definition in 5.5.2:
>
> Schema Definition:
>
>   <!-- use these element types as children of EncryptionMethod
>
> when used with RSA-OAEP -->
>
>   <element name="OAEPparams" minOccurs="0" type="base64Binary"/>
>
>   <element ref="ds:DigestMethod" minOccurs="0"/>
>
>   <element name="MGF" type="xenc11:MGFType"/>
>
>
> This isn't really a normative schema, and I think that's the problem here.
> It's presented in a questionable way because it's trying to show the
> content model that is imposed by the text, but there is no actual schema
> enforcing this. And as it stands, it's misrepresenting the MGF and
> OAEPparams elements because it's giving them both "names" in the same
> default namespace.
>
> Basically you can't informally present things like this without running
> into problems.
>
> At the very least, it shouldn't be called a "Schema". I'm not sure what
> can really be done here, but at a minimum you'd have to maybe split the
> schema fragments being presented in the two separate schemas. Personally,
> I would just use prose to describe the element content, and then maybe
> just show the schema for the new element being defined here, the MGF.
>
> -- Scott
>
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
Received on Wednesday, 18 January 2012 04:23:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 January 2012 04:24:00 GMT