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

Re: XMLDSIG RSA signatures

From: merlin <merlin@baltimore.ie>
Date: Tue, 29 Aug 2000 17:24:32 +0100
Message-Id: <200008291624.RAA01639@cougar.baltimore.ie>
To: "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)
  or
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. The former is a legitimate choice that we should
make in the standard. We have to make a choice because it may
fundamentally affect how crypto toolkits are invoked,
particularly where hardware is concerned.

Merlin

r/bfox@Exchange.Microsoft.com/2000.08.29/09:03:42

>Merlin:
>
>I don't strongly object to making this change in the draft but I
>disagree that it mandates ASN.1 parsing.  It doesn't.  It's just a
>recognizable blob -- and a fact of life for users of existing toolkits.
>
>
>--Barb
>=20
>
>-----Original Message-----
>From: merlin [mailto:merlin@baltimore.ie]
>Sent: Tuesday, August 29, 2000 8:51 AM
>To: Barb Fox
>Cc: Gregor Karlinger; w3c-ietf-xmldsig@w3.org
>Subject: Re: XMLDSIG RSA signatures=20
>
>
>
>Hi,
>
>We must already massage DSA signatures to meet the XMLDSIG
>encoding; I would strongly endorse a requirement that
>RSA signatures MUST be massaged into the simplest form too.
>
>For crypto environments such as you describe, the effort is
>no greater than the DSA massage; for everyone else, life
>would be much simpler.
>
>Merely having the option of an OID turns ASN.1 parsing into
>a mandatory requirement of all toolkits that wish to interop,
>which is expressly undesirable.
>
>Merlin
>
>r/bfox@Exchange.Microsoft.com/2000.08.29/08:13:21
>>
>>The reason that I added this as a MAY is because many toolkits
>>automatically pre-pend that OID in an RSA signature.=3D20
>>
>>--Barb
>>
>>-----Original Message-----
>>From: Gregor Karlinger [mailto:gregor.karlinger@iaik.at]
>>Sent: Tuesday, August 29, 2000 7:02 AM
>>To: merlin; w3c-ietf-xmldsig@w3.org
>>Subject: AW: XMLDSIG RSA signatures
>>
>>
>>Hi all,
>>
>>I agree with Merlin, providing the option to wrap the RSA signature
>>octets
>>into
>>a ASN.1 structure, however it looks like
>>
>>  * has no benefits ,
>>  * adds options which result in a more complicated verification
>>process,
>>  * is confusing (I had to read the text in 6.4.2 some times to get
>it).
>>
>>Therefore I also vote to kick this option out.
>>
>>Regards, Gregor
>>---------------------------------------------------------------
>>Gregor Karlinger
>>mailto://gregor.karlinger@iaik.at
>>http://www.iaik.at
>>Phone +43 316 873 5541
>>Institute for Applied Information Processing and Communications
>>Austria
>>---------------------------------------------------------------
>>
>>
>>> Hi,
>>>
>>> In 6.4.2, regarding RSA signatures, the following wording exists:
>>>
>>>   A signature MAY contain a pre-pended algorithm object identifier,
>>>   but the availability of an ASN.1 parser and recognition of OIDs is
>>>   not required of a signature verifier.
>>>
>>> Does this mean that a signature may be (before base 64 encoding):
>>>
>>>   SEQUENCE { SEQUENCE { OID . NULL } . BIT_STRING { SIGNATURE_VALUE }
>>}
>>> or:
>>>   SEQUENCE { OID . NULL } . BIT_STRING { SIGNATURE_VALUE }
>>> or:
>>>   SEQUENCE { OID . NULL } . SIGNATURE_VALUE
>>> or:
>>>   OID . SIGNATURE_VALUE
>>>
>>> Or, is it suggesting that the OID _within_ the RSA signature
>>> (before crypting) is optional?
>>>
>>> Regardless, I think it adds options and thus confusion and thus
>>> deserves, perhaps, to be eliminated..
>>>
>>> merlin
Received on Tuesday, 29 August 2000 12:25:10 GMT

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