Re: xmldsig questions

I was thinking that an  OCSP status response would require a special
element to indicate what it is, similarly to CRLs, just so there is no
need to agree in advance on an element. Depending on the business model,
it can be valuable to pass a signed OCSP response with a transaction so
the receiver does not need to perform a check.

I gather that a subsequent version of OCSP *may* use XML, or that there
is an independent effort to do this, but the current RFC 2560 is not
using XML.

What I am hearing is that we could just treat this as any other kind of
application specific data. What I am suggesting is that by defining the
element (tag) we may make it easier to support applications which want
to include an OCSP  response in a transaction, since the element will be
standard.

I do not want to sidetrack the effort, but since we have X509CRL defined
in X509Data, I thought X509OCSP would be logical, since lots of projects
use OCSP instead of CRLs.

thanks

< Frederick

"Barb Fox (Exchange)" wrote:

>
>
> Tom:
>
> 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
>
> (snip)
> 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?