- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 13 Feb 2009 16:40:23 +0100
- To: Sean Mullan <Sean.Mullan@Sun.COM>
- Cc: XMLSec WG <public-xmlsec@w3.org>
I've updated the editor's draft accordingly. (ACTION-209) -- Thomas Roessler, W3C <tlr@w3.org> On 4 Feb 2009, at 20:04, Sean Mullan wrote: > Also, a comment was sent to me that we should probably be specific > about the encoding, given the certificate ambiguity encoding issues. > So I suggest: > > o The OCSPResponse element contains a base64-encoding of a DER- > encoded OCSP Response [OCSP]. > > > Thomas Roessler wrote: >> On 3 Feb 2009, at 19:33, Sean Mullan wrote: >>> >>> (I'm not sure my schema/dtd syntax is correct, but here's my >>> proposal for an AI from the F2F. Please review.): >>> >>> Add the following bullet to the part titled "1. At least one >>> element ..." in section 4.4.4 The X509Data Element : >>> >>> o The OCSPResponse element contains a base64-encoded OCSP Response >>> [OCSP]. >> Please make this "The dsig11:OCSPResponse element" >>> Add the following entry to the schema definition and DTD at the >>> end of section 4.4.4: >>> >>> <element name="OCSPResponse" xmlns="http://www.w3.org/2009/xmldsig11# >>> " type="base64binary"/> >> That xmlns attribute puts <element/> into disg11:, not OCSPResponse. >> Therefore, we'll want to have this in a separate schema block >> (which clearly says in the text around it that it's for dsig11:): >> <element name="OCSPResponse" type="base64binary"/> >>> OCSP >>> RFC 2560. X.509 Internet Public Key Infrastructure Online >>> Certificate Status Protocol - OCSP. M. Myers, R. Ankney, A. >>> Malpani >>> S. Galperin, C. Adams. June 1999. >>> http://www.ietf.org/rfc/rfc2560.txt >
Received on Friday, 13 February 2009 15:40:34 UTC