- From: Richard D. Brown <rdbrown@Globeset.com>
- Date: Fri, 13 Aug 1999 18:01:50 -0500
- To: "'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>
Barb, > (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 Agreed DH is a difficult issue. But can we just ignore it? DH has some interesting properties... > > (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. Recall that I do not refer to the value of the key nor the value of a certificate or certificate chain - I just argue about an unambiguous signer identifier from the perspective of the relying party(ies). I do not understand your point wrt "baked-in". Where? Supposedly in the signer device. This will not help the relying party identify the signer (at least to retrieve a copy of the key). > > (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. I used an attribute certificate as an example. Recall that I have been among the firsts to insist on authentication schemes. And I certainly agree that in such circumstances we care less about a certificate. But there are others that need them (attached or not to the message). Richard D.
Received on Friday, 13 August 1999 19:01:55 UTC