Subject: Requirements for SCVP over HTTP

From: "David A. Cooper" <[email-masked]>
Date: Fri, 31 Aug 2007 13:08:11 -0400

At 5:17 PM 7/6/2007, David A. Cooper wrote:
> I just submitted draft 32 of SCVP for posting.  This draft contains 
> some editorial changes to address comments raised as a result of IESG 
> review, but there are no changes to the protocol, either syntactic or 
> semantic.  A diff file comparing drafts 31 and 32 is available at 
> http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-31_to_32.html. 
>
>
> I should note that this draft does not address every issue raised 
> during the IESG review.  In particular, there are still outstanding 
> comments from Lisa Dusseault relating to the use of HTTP, which is 
> mainly specified in Appendix B of SCVP.  Lisa's comments may be found 
> at 
> https://datatracker.ietf.org/idtracker/draft-ietf-pkix-scvp/comment/65322.  
> If there is someone who has a sufficient knowledge of HTTP to address 
> the issues that Lisa raises and who is willing to work with us to 
> resolve these issues, that would be appreciated.
All,

As noted in the minutes from the PKIX session at the July IETF 
(http://www3.ietf.org/proceedings/07jul/minutes/pkix.htm), Paul Hoffman 
has been working to develop new text for Appendix B of SCVP to address 
Lisa Dusseault's comments.  As a result of feedback received since July, 
Paul decided to develop a proposal that describes the use of HTTP.  
Paul's proposed text for Appendix B is at the end of this email.  Paul 
has discussed this proposal with Lisa, and she believes that the text 
addresses her concerns.

Please review this text and provide any comments by Friday, September 14.

Thanks,

Dave

-------------------------------------------------------------------------------------
Appendix B.  SCVP over HTTP

   This appendix describes the formatting conventions for the SCVP
   request and response when carried by HTTP.

   In order for SCVP clients and servers using HTTP to interoperate,
   the following rules apply.

   - Clients MUST use the POST method to submit their requests.

   - Servers MUST use the 200 response code for successful responses.

   - Clients MAY attempt to send HTTP requests using TLS 1.0 or
   later over port 443, although servers are not required to support
   TLS.

   - Servers MUST NOT assume client support for any type of HTTP
   authentication such as cookies, Basic authentication, or Digest
   authentication.

   - Clients and servers are expected to follow the other rules and
   restrictions in RFC 2616. Note that some of those rules are for
   HTTP methods other than POST; clearly, only the rules that apply to
   POST are relevant for this specification.

B.1  SCVP Request

   An SCVP request using the POST method is constructed as follows:

       The Content-Type header MUST have the value
       "application/scvp-cv-request".

       The body of the message is the binary value of the DER encoding
       of the CVRequest, wrapped in a CMS body as described in Section
       3.

B.2  SCVP Response

   An HTTP-based SCVP response is composed of the appropriate HTTP
   headers, followed by the binary value of the BER encoding of the
   CVResponse, wrapped in a CMS body as described in Section 4.

   The Content-Type header MUST have the value "application/scvp-cv-
   response".

B.3  SCVP Policy Request

   An SCVP request using the POST method is constructed as follows:

       The Content-Type header MUST have the value
       "application/scvp-vp-request".

       The body of the message is the binary value of the BER encoding
       of the ValPolRequest, wrapped in a CMS body as described in
       Section 5.

B.4  SCVP Policy Response

   An HTTP-based SCVP policy response is composed of the appropriate
   HTTP headers, followed by the binary value of the DER encoding of the
   ValPolResponse, wrapped in a CMS body as described in Section 6.

   The Content-Type header MUST have the value "application/scvp-vp-
   response".