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

New element definition added to 1.1 XML Signature Schema

From: <Frederick.Hirsch@nokia.com>
Date: Sat, 2 Oct 2010 01:38:18 +0200
To: <eb2m-mrt@asahi-net.or.jp>
CC: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>
Message-ID: <62CE6941-6E57-492E-B83F-A1773459839A@nokia.com>

We've added a new element definition to the XML SIgnature 1.1 schema, as noted in the message below. The XSD schema is as follows:

<element name="X509Digest" type="dsig11:X509DigestType"/>
<complexType name="X509DigestType">
     <extension base="base64Binary">
       <attribute name="Algorithm" type="anyURI" use="required"/>

It is another optional child of X509Data.

I added the following to the RELAX NG compact form schema in xmldsig11-schema.rnc:

ds_X509DataChild |= dsig11_X509Digest

dsig11_X509Digest = 
  attribute Algorithm { xsd:anyURI },

Does this look correct to you?

I also used trang to generate the xmldsig11-schema.rng file.


regards, Frederick

Frederick Hirsch

Begin forwarded message:

> From: ext Scott Cantor <cantor.2@osu.edu>
> Date: September 21, 2010 11:48:17 AM EDT
> To: "public-xmlsec@w3.org" <public-xmlsec@w3.org>
> Subject: ACTION-665: Devise proposal for X509SerialNumber (v2)
> Incorporating the decisions on Algorithm handling, a couple of nits, and the
> concern about reuse:
> In section 4.5, add a URL to the list of new 1.1 RetrievalMethod URLs:
> "http://www.w3.org/2009/xmldsig11#X509Digest"
> In section 4.5.4, alter the first bullet under item 1, which describes
> X509IssuerSerial:
> "The deprecated X509IssuerSerial element..."
> (I suspect that item numbering is a formatting mistake, there's no number
> 2.)
> Move the bullet on "extensions in other namespaces" to the end of the list
> (after this new element).
> Add a new bullet under OCSPResponse:
> "The dsig11:X509Digest element contains a base64-encoded digest of a
> certificate. The digest algorithm URI is identified with a required
> Algorithm attribute. The input to the digest MUST be the raw octets that
> would be base64-encoded were the same certificate to appear in the
> X509Certificate element."
> Add dsig11::X509Digest to the lists of elements in both paragraphs below
> the bulleted list:
> "Any X509IssuerSerial, X509SKI, X509SubjectName, and dsig11:X509Digest
> elements..."
> Add a new paragraph following those two paragraphs:
> "Note that if X509Data elements are used to identify a trusted certificate
> (rather than solely as an untrusted hint supplemented by validation by
> policy), the complete set of such elements that are intended to identify a
> certificate SHOULD be integrity protected, typically by signing an entire
> X509Data or KeyInfo element."
> Modify the last paragraph in the section that discusses X509IssuerSerial:
> "The X509IssuerSerial element has been deprecated in favor of the
> newly-introduced X509Digest element. The XML Schema type of the serial
> number was defined to be an integer, and XML Schema validators may not
> support integer types with decimal data exceeding 18 decimal digits
> [XML-schema]. This has proven insufficient, because many Certificate
> Authorities issue certificates with large, random serial numbers that exceed
> this limit. As a result, deployments that do make use of this element should
> take care if schema validation is involved. New deployments SHOULD avoid use
> of the element."
> Finally, add schema below the definition of OCSPResponse (and to the actual
> schema of course):
> <element name="X509Digest" type="dsig11:X509DigestType"/>
> <complexType name="X509DigestType">
>  <simpleContent>
>     <extension base="base64Binary">
>       <attribute name="Algorithm" type="anyURI" use="required"/>
>     </extension>
>  </simpleContent>
> </complexType>
> -- Scott
Received on Friday, 1 October 2010 23:39:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:14 UTC