- From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
- Date: Fri, 13 Aug 1999 15:29:49 -0700
- 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 UTC