W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

RE: XMLDSIG RSA signatures

From: Philip Hallam-Baker <pbaker@verisign.com>
Date: Tue, 29 Aug 2000 09:54:59 -0700
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EBF2@vhqpostal.verisign.com>
To: "'merlin'" <merlin@baltimore.ie>, Barb Fox <bfox@Exchange.Microsoft.com>
Cc: Gregor Karlinger <gregor.karlinger@iaik.at>, w3c-ietf-xmldsig@w3.org
> Hi,
> Can we first clarify what the sentence actually means?
> 1) The signature may be either an encrypted ASN.1 blob (PKCS#1)
> or an encrypted raw digest (like W?TLS)

Oh #(@!%& they didn't did they?

If they didn't know about the chosen digest attack what is
the chance they know about the associativity attacks? Oh @)*@#!

> 2) The signature is always an encrypted ASN.1 blob (PKCS#1) but
> it may be wrapped/prepended/... by an ASN.1 OID.
> The latter imposes some unnecessary knowledge of ASN.1 upon
> the XMLDSIG toolit, and it is still not clear what encoding
> is suggested. 

There is ASN.1 and there is ASN.1.

I don't know of ANY toolkit that actually uses an ASN.1 compiler
to generate the crypto blob level structures.

The problem with the versioning URI is that the XML toolkit needs
to map the versioning URI onto the corresponding OID when it
contacts the crypto toolkit. This requires the XML toolkit
to know rather more about the underlying crypto than you might
want - especialy in the case where you have multiple toolkits
for different algorithms.

We could make this whole system a little simpler though if we
just insist that all ASN.1 structures be prefixed by their
OID blob - i.e.


and not 


I would advocate the same for the X.509 structures.

The advantage of doing this is that the XML aware layer can then
route data based on a simple string comparison of the leading
octets of the data blob.

Dropping out the SEQUENCE OF {SET OF {MANGLING OF { prefixes
makes the whole system work much better.


Received on Tuesday, 29 August 2000 12:56:29 UTC

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