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

RE: xmldsig questions

From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
Date: Tue, 21 Dec 1999 10:47:05 -0800
Message-ID: <4992824A0863D211964B0008C7B1ACB803E1BBE3@fifi.platinum.corp.microsoft.com>
To: "'tgindin@us.ibm.com'" <tgindin@us.ibm.com>
Cc: w3c-ietf-xmldsig@w3.org

I don't mind pulling CRL out, but it seems like an ASN.1 structure that some
people might want if they choose to use certificates. Responses to
certificate revocation status requests, as Phill points out, can be XML
formatted messages. 

--Barbara Fox

-----Original Message-----
From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
Sent: Tuesday, December 21, 1999 7:40 AM
To: Barb Fox (Exchange)
Cc: 'Joseph M. Reagle Jr.'; Frederick Hirsch; w3c-ietf-xmldsig@w3.org;
John Boyer; David Solo
Subject: RE: xmldsig questions

David, Barbara, others?

(Barb) X509OCSP: This isn't a big deal to add, but it has the potential to
open a can of snakes that we've carefully tried to avoid, "freshness of
certificates." We don't require certificates in XML signatures. They're
just one form of evidence that MAY be provided by a signer to a verifier.
Attaching an OCSP response could be considered additional evidence. What we
want to avoid tho is our making any implied recommendations about signers
having to get and attach OCSP responses (or certs, for that matter) to
their signed documents. An OCSP response in particular seems pretty silly
since if a verifier wants freshness information about a certificate, he can
get his own OCSP response.

[Tom Gindin]   For non-repudiation, it can be important to preserve
evidence that the signer's certificate was valid at the time of signature,
and an OCSP or SCVP response is perfectly reasonable as a way of preserving
evidence that it was valid at the signing time.  Is there any other reason
to put a CRL in the KeyInfo, since the verifier can get it almost as easily
as he can get an OCSP response?
Received on Tuesday, 21 December 1999 13:46:59 UTC

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