W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2006

Re: RFC: new SignatureAlgorithm for web browser interop

From: Mikolaj Habryn <dichro@rcpt.to>
Date: Mon, 01 May 2006 11:03:32 +1000
To: w3c-ietf-xmldsig@w3.org
Message-Id: <1146445414.13478.113.camel@mh.optusnet.com.au>
Greetings to anyone interested. Some more details on how this is
proposed to work, a minimal schema to support validating web-signed XML,
and some implementation experience.

To recap briefly, the point of the exercise is to use Mozilla's
crypto.signText Javascript method to generate an XML-Signature compliant
document. Since this particular method results in a PKCS#7 signature,
the relevant data needs to be extracted from the ASN.1 blob to reformat
into a ds:Signature block, and a new SignatureAlgorithm is required for
validation.

An example is worth a thousand or so words, so here's what the eventual
signature looks like, with some elisions. The section of interest is the
subtree under ds:SignatureMethod.

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
  <ds:SignatureMethod Algorithm="http://mikolaj.cx/xmldsig-pkcs#rsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
   <AuthenticatedAttributes xmlns="http://mikolaj.cx/xmldsig-pkcs#">
    <ContentType><ContentTypeData/></ContentType>
    <SigningTime>2006-05-01T00:28:33Z</SigningTime>
    <MessageDigest/>
   </AuthenticatedAttributes>
  </ds:SignatureMethod>
  <ds:Reference URI="#xpointer(/)" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
   </ds:Transforms>
   <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
   <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">xkfYbqvir3zzP4aDujFmD2n7UBo=</ds:DigestValue>
  </ds:Reference>
 </ds:SignedInfo>
 <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  ...
 </ds:SignatureValue>
 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  ...
 </ds:KeyInfo>
</ds:Signature>

This basically represents the contents of the browser-generated
signature. The signed PKCS#7 attributes are content type, signing time
and message digest. The former two are represented literally under the
SignatureMethod element, whereas the message digest is merely a
placeholder for the purposes of correctly ordering the authenticated
attributes during verification, and is substituted with the value from
the Reference block.

A (minimal!) schema allowing for validation of this block is attached;
it is missing all of the other PKCS#7 authenticated attributes that
could conceivably be included in the signature, as well as handling of
multi-valued attributes.

I've knocked up a basic web form which uses boilerplate substitution to
generate a C14N'd XML document (it may be possible to use Javascript DOM
routines to do so, haven't experimented with it), browser signing, a web
service to convert the signature, and then more Javascript to wrap and
submit the signed document as a SOAP message. It's actually surprisingly
easy to do (http://wiki.rcpt.to:8180/settlement/balance.html shows the
code) as long as one doesn't attempt to do the ASN.1 decomposition
client side.

While this is functional as presented, it's questionable whether the
current user experience is terribly meaningful, obfuscating as it does
the actual data being signed in an XML-unaware confirmation dialog,
particularly when the code that assembles the data to be signed is being
downloaded from a remote location. This could be ameliorated to some
extent by designing the schema to present the most important data early
in the document and using the standard mechanisms to assure trust
between client and server, however it's still somewhat clunky.

Nonetheless, I think this has some value as a bridge between PKCS-only
signature engines and XML-Signature, and since I need it sooner rather
than later, I intend to write it up for submission as an I-D, using
something similar to http://mikolaj.cx/xmldsig-pkcs# as the algorithm
URI and schema namespace.

m.

<xsd:schema
  targetNamespace="http://mikolaj.cx/xmldsig-pkcs#"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://mikolaj.cx/xmldsig-pkcs#"
  elementFormDefault="qualified">

  <xsd:complexType name="emptyType"/>

  <xsd:complexType name="contentType">
    <xsd:choice>
      <xsd:element name="ContentTypeData" type="emptyType"/>
    </xsd:choice>
  </xsd:complexType>

  <xsd:complexType name="authenticatedAttributes">
    <xsd:choice maxOccurs="unbounded">
      <xsd:element name="ContentType" type="contentType"/>
      <xsd:element name="SigningTime" type="xsd:dateTime"/>
      <xsd:element name="MessageDigest" type="emptyType"/>
    </xsd:choice>
  </xsd:complexType>

  <xsd:element name="AuthenticatedAttributes" type="authenticatedAttributes"/>

</xsd:schema>
Received on Monday, 1 May 2006 01:02:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:40 UTC