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

RE: Revised syntax proposal

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>
Message-ID: <016301bee5df$d47dbb30$0bc0010a@artemis.globeset.com>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:31 UTC