RE: xmldsig questions

> >4. In section 3.4, KeyInfo, I note that the spec allows including a
> >CRL, with element X509CRL. Can we also define including signed OCSP
> >responses, with an X509OCSP element? This would allow transmitted the
> >status of the certs with a transaction in an interoperable manner.

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

Actually I would avoid the construct for a quite different reason. OCSP
responses are mainly constructed on an ad-hoc basis in response to an
actual request. I don't see particular value in embedding ASN.1 structures
of that type in XML documents. The OCSP server should have the manners
to deliver the data in XML syntax.

So while I think there is a value in incorporating an OCSP token in a sig
package I don't think we want to assume that it will be PKIX OCSPv1 in
ASN1 format. In fact one of the original reasons for supporting a variant
response syntax in OCSP was to allow an XML reply.

In fact I have recently been rewritting OCSP-X to exclude the
'controvertial'
Authorization functionality and rolled that into an XML based OCSP draft
for experimental track just so it does not get patented by some louse.
[Don't expect the drafts till I have spare time to finish 'em though]

	Phill

Received on Tuesday, 21 December 1999 10:23:56 UTC