- From: Sean Mullan <Sean.Mullan@Sun.COM>
- Date: Wed, 04 Feb 2009 14:04:33 -0500
- To: Thomas Roessler <tlr@w3.org>
- Cc: XMLSec WG <public-xmlsec@w3.org>
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 Wednesday, 4 February 2009 19:05:24 UTC