Re: XML-Signature Working Draft

Pete,

From:  Pete Chown <Pete.Chown@skygate.co.uk>
Date:  Thu, 2 Dec 1999 17:00:19 +0000
Message-ID:  <19991202170019.A1028@hyena.skygate.co.uk>

>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.

The charter of the working group is to define an XML syntax for
signatures.  My opinion and that of the working group as far as I can
tell, is that just defining, an <OpenPGPsiganture> element and saying
that you stuff the base64 of an OpenPGP signature inside it, isn't an
XML signature syntax in any reasonable sense.  It's an OpenPGP syntax
signature being carried in XML.  For something to be an XML signature
syntax, the essential elements of the signature, including digest and
siganture algorithms, keying information and signature properties if
present, etc., need to be represented in and manipulatable as XML.

I don't see much point in arguing how much gain this is as it all
depends on your point of view.

Of course, if you wish to, you can define an "OpenPGP" siganture
algorithm which stuffs an OpenPGP signature into the SignatureValue
and pretty much ignores everything else by putting in dummy values.

>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.

You seem to understand quite well.  A key is a key.  Is hardly matters
whether it is buried inside a PGP or X509 blob as long as you or your
crypto library can extract it.

>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.)

If you are talking about the optional capability of canonicalization
of SignedInfo, it is to have the signature be robust in the face of
the modifications to the data required by the XML 1.0 standard on
reading/parsing XML and the modifications to the data performed by the
commonly used SAX and standard DOM interfaces and the requirement
that, after being processed by DOM or SAX, the data be re-serialized.
I suggest you look closely at the XML 1.0 and DOM standards.

>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?

This is an interesting point no one has brought up before.  Two
reasons come to mind immediately:

(1) So you can distinguish between the signature getting corrupted and
the data getting corrupted or not being properly located or decoded.

(2) In the case of Manifest's, with the current syntax, so you can
validate the hash over the Manifest without having to fetch all the
data.  This is required in many scenarios.

>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.

Others on the working group mailing list who are more knowlegeable in
this area than myself say that active work is occuring on developing
improved hash/disgest algorithms and that some of this work is closely
related to AES.

>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.

Did you also read the requirements document which is linked off the
WG home page at <http://www.w3.org/Signature>?

>----------------------------------------------------------------------
>      phone +44 (0) 20 8542 7856, fax +44 (0) 20 8543 0176, post:
>  Skygate Technology Ltd, 8 Lombard Road, Wimbledon, London, SW19 3TZ

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA

Received on Thursday, 2 December 1999 14:54:43 UTC