W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

XML-Signature Working Draft

From: by way of <Pete.Chown@skygate.co.uk>
Date: Thu, 02 Dec 1999 12:37:09 -0500
Message-Id: <3.0.5.32.19991202123709.00a14680@localhost>
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Hello,

I had a look at the XML-Signature working draft today, and I have a
few comments.

1.  You define new digital signature formats.

My most important concern is that the document seems to define a new
format for digital signatures.  Instead of simply saying that a block
of text is signed using OpenPGP (for example) you actually go to a
lower level and indicate the actual signature algorithm (DSA, RSA and
so on).

This seems to create a lot of work for implementors without any gain.
It also increases the risk of insecure implementations.  Instead of
one piece of security-critical code which can be extensively peer
reviewed, there will now be a multiplicity of them.

2.  It is unclear how OpenPGP and S/MIME keys are used for signature.

I noticed that the specification permits OpenPGP and S/MIME keys to be
included with signatures.  This is obviously sensible.  However I am
unclear how these keys are to be used, unless the DSA or RSA
parameters are to be extracted and then used in forming the signature.

3.  What is the justification for canonicalisation prior to signature?

Perhaps I am missing something, but I fail to see the point of this.
The signature can be calculated by treating the data to be signed as a
simple octet stream without doing any additional manipulations.  (Of
course, as you point out, something has to be done with entity
references or it introduces a security weakness.)

4.  I am not sure why the digest values are included in the XML.

When verifying the signature you have to recalculate the digest
values anyway, so is there any point in including them in the
document?

5.  I am puzzled by the statement that digest algorithms will come
    from the AES effort.

The AES effort is aimed at selecting a new block cipher, not at
developing digest algorithms.  Of course, a block cipher can be used
as a digest algorithm through something like MDC-2 but this is much
less efficient than a specialised digest algorithm like SHA-1.  It can
also be done satisfactorily with pre-AES ciphers such as Blowfish.

I'm sorry if I'm missing something here; it is hard to comment just on
a document seen in isolation without being a party to the discussions
that led up to it.  However, I feel these issues are important -- I am
likely to have to implement something based on this, and at the moment
it looks as though it will be an order of magnitude more work than it
needs to be.  OpenPGP signatures especially are easy because all the
code already exists -- we can just use PGP or the GNU Privacy Guard.

----------------------------------------------------------------------
      phone +44 (0) 20 8542 7856, fax +44 (0) 20 8543 0176, post:
  Skygate Technology Ltd, 8 Lombard Road, Wimbledon, London, SW19 3TZ
Received on Thursday, 2 December 1999 12:38:11 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT