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

RE: Revised syntax proposal

From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
Date: Fri, 13 Aug 1999 15:29:49 -0700
Message-ID: <4992824A0863D211964B0008C7B1ACB803E1B766@FIFI.platinum.corp.microsoft.com>
To: "'rdbrown@Globeset.com'" <rdbrown@Globeset.com>, "Barb Fox (Exchange)" <bfox@Exchange.Microsoft.com>, "'David Solo'" <david.solo@citicorp.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: w3c-ietf-xmldsig@w3.org
Richard:

(1) Yes, we discussed KeyInfo in Oslo, but I recall that the real issue then
was more RecipientInfo and D-H. People (including me, of course) didn't want
to carry that baggage forward from S/MIME -- nor do I want to carry forward
SignerInfo. It doesn't really matter tho, and since there was no
chair-sponsored straw poll to resolve lots of mailing list discussion, the
issue is still open. 

(2) While I agree that the signer must be identified sometime/somehow, this
info doesn't have to become overhead in every message. In small devices, the
keys could even be baked-in. 

(3) Signing authority? What signing authority? Again, you're assuming a
certified key even if it's an attribute certificate with id + serial number.
I still argue that assuming a certificate of any kind is a bad idea for XML.
Think about signed XML used for authenticated messages. Why would you need
ASN.1/X.509 path validation in that environment? You don't. 

My only real concern at this point however, is that we do not enough
discussion going on this list to get a real wg consensus and an eventual
standard. Maybe everybody is on vacation???

--barb

-----Original Message-----
From: Richard D. Brown [mailto:rdbrown@Globeset.com]
Sent: Friday, August 13, 1999 3:09 PM
To: 'Barb Fox (Exchange)'; 'David Solo'; 'Phillip M Hallam-Baker'
Cc: w3c-ietf-xmldsig@w3.org
Subject: RE: Revised syntax proposal


Barb,

> Barb Comments:
>
> I have three problems with this:
>
> (1) KeyInfo in PKIX means the algorithm and the key. What
> you're talking
> about is along the lines of SignerInfo in CMS (where the set,
> of course may
> be 0). If it has to survive, then at let's change the name.
>
> (2) For many signed XML applications, there are going to be only
> pre-negotiated keys, so this KeyInfo can't be mandatory.
>
> (3) My strongest objection though is that your KeyInfo
> attaches semantics to
> the signature (or presumes that a cert does) which is outside
> the scope of
> this wg.

 Mine:

(1) Recall, KeyInfo used to be the pair OriginatorInfo and RecipientInfo.
This has been changed in Oslo. At that time, it was not question about
changing the semantics of these fields - just to group them together and
change the name.

(2) Though the keys can be pre-negotiated (e.g. AADS), somewhere you need to
identify the signer in order to retrieve his key. This can be dealed with
either at the application level (which passes the key per value to the
verification engine) or at the signature level (which calls out some
provider to retrieve the key).

(3) NO! it only presumes that unambiguous identification of the signing
authority is important. How strong is a signature if one can substitute the
signing authority by another without being detected. Although such tampering
is pretty much limited to a single individual/organization that uses a same
key for a plurality of purposes. But, there are many circumstances where the
authority primes over the identity, and this is pretty much why many argue
against identity certificates and promote attribute certificates. The key is
not necessarily everything - The identity as well.

Richard D.
Received on Friday, 13 August 1999 18:32:48 GMT

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