RE: XMLDSIG RSA signatures

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

OID . SIGNATURE_VALUE 

and not 

SEQUENCE { SEQUENCE { OID . NULL } . BIT_STRING { SIGNATURE_VALUE }
etc.

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.


		Phill