[whatwg] Signed XHTML

[Martin Boßlet]

First of all, thanks a lot for your comments!

2011/10/31 Mike Hanson <mhanson at mozilla.com>:
> On Oct 31, 2011, at 3:53 AM, Mikko Rantalainen wrote:
>
>> 2011-10-27 14:29 EEST: Henri Sivonen:
>>> On Thu, Oct 20, 2011 at 9:57 PM, Martin Boßlet
>>> <martin.bosslet at googlemail.com> wrote:
>>>> Are there plans in this direction? Would functionality like this have a
>>>> chance to be considered for the standard?
>>>
>>> The chances are extremely slim.
>>>
>>> XML signatures depend on XML canonicalization which is notoriously
>>> difficult to implement correctly and suffers from interop problems
>>> because unmatched sets of bugs in the canonicalization phase make
>>> signature verification fail. I think browser vendors would be
>>> reasonable if they resisted making XML signatures of canonicalization
>>> part of the platform.
>>>
>>> Moreover, most of the Web is HTML, so enthusiasm for XHTML-only
>>> features is likely very low these days.
>>
>> I agree. If a method for signature would be introduced, it should be on
>> HTTP-level instead. For example, the server (or client) could pass an
>> extra header (e.g. Content-Signature) where value would be the signature
>> of the content with some extra info about the key&algorithm used for
>> signature.

Sure, XHTML-only features might not be as popular, but being XHTML-only
should not be held against the idea? If you want to use the feature, you
have to ensure your site is XHTML. That seems acceptable to me, using
the feature will put no additional burden (other than ignoring <dsig:Signature>
elements) on those who do not want to use/support it.

I also agree that C14N can be a real pain, but again I would argue that
being hard alone should not immediately disqualify it. TLS is also hard,
I would say harder even and yet it is a common feature. With broader
acceptance and usage the interoperability issues should vanish.
There are also open source implementations (libxml, Apache Santuario,
XOM) that could help sorting them out.

I like the 'Content-Signature' idea, it's similar to what Mike proposes,
however I still think XML signatures offer more flexibility (see below).

> And, for the record, S/MIME already defines the application/pkcs7-signature MIME type for signed message-bodies (see RFC 5751 for the latest).
>
> Support for S/MIME response processing in browsers is thin-to-nonexistent, but business-to-business exchange of S/MIME signed bodies over HTTP has been around for many years.  It at least has the benefit of not requiring canonicalization, since the signature algortithm is defined to run over the serialized bytes of the message.
>
> The main reason to push for signatures in the body of a message would be because there was desire to sign a sub-region of the document, or to support multiple or partially-trusted signers; the use cases for that are quite rarified at this point.
>

Indeed, being part of the document itself is the greatest advantage
of XML signatures over traditional CMS-based signatures. With CMS
there is always the problem of how to keep document and separate
signature together. I understand your concern about supporting this,
but my argument for still including the feature would be that it doesn't
really require much effort to provide basic support: extending XSDs,
and browsers could simply suppress rendering a <dsig:Signature>
element as minimal default support.

The point for CMS signatures not requiring canonicalization could
actually also be held against it,  for the reasons why C14N was
needed: due to the "fragility" of the XML format, some parsers
actively alter content of an XML document when parsing it, therefore
ultimately breaking a CMS signature that was ran over the initial
byte representation...

Some benefits of XML signatures that would not be possible using
CMS-based signatures, taken from the top of my head :

- Being a part of the document itself, we can easily view signed documents
in the browser itself along with the signature information, similar to what's
possible with signed PDFs. The concept is much easier to convey to
casual users than to try explaining them the benefits of a separate CMS
signature file, probably requiring a separate viewer.

- XML signatures allow to imitate any complex scenario of co- and
countersignatures, e.g. it's possible to do something like "sign top-level
signatures A and B plus the countersignature of C, but not C itself".
There's no (non-proprietary or efficient) way of doing this in CMS
simply due to the lack of being able to cross-reference between
different elements in ASN.1/DER.

- The possibility to sign only parts of the XML - when combined with
exclusive C14N this allows to reuse a signature together with its signed
part in multiple documents. This could actually be quite useful when a site
is doing a mashup of remotely downloaded content. Currently there's not
much to help making this secure - if the remote content were at least signed
we would at least be able to judge the authenticity and integrity of what was
downloaded.

I'm quite positive that the imagination and creativity of others could certainly
produce a lot more attractive use cases. To conclude my thoughts, my
argument for supporting XML signatures is that while not being too much
effort to support, they could still open the door for interesting and useful
applications that would otherwise not be possible.

-Martin