CA Capabilities

C.1. GetCACaps HTTP Message Format

   "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT

   This message requests capabilities from CA.  The response is a list
   of text capabilities, as defined in Appendix C.2.  Support for this
   message is OPTIONAL, but if it is not supported, the client SHOULD
   assume that none of the capabilities in Appendix C.2 are supported.

C.2. CA Capabilities Response Format

   The response for a GetCACaps message is a list of CA capabilities, in
   plain text, separated by <LF> characters, as follows (quotation marks
   are NOT sent):

Appendix C.2 

Pritikin, et al.         Expires March 10, 2012                [Page 40]

 
Internet-Draft                    SCEP                    September 2011


   +--------------------+----------------------------------------------+
   | Keyword            | Description                                  |
   +--------------------+----------------------------------------------+
   | "GetNextCACert"    | CA Supports the GetNextCACert message.       |
   | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP   |
   |                    | POST.                                        |
   | "Renewal"          | Clients may use current certificate and key  |
   |                    | to authenticate an enrollment request for a  |
   |                    | new certificate.                             |
   | "SHA-512"          | CA Supports the SHA-512 hashing algorithm.   |
   | "SHA-256"          | CA Supports the SHA-256 hashing algorithm.   |
   | "SHA-1"            | CA Supports the SHA-1 hashing algorithm.     |
   | "DES3"             | CA Supports the Triple-DES encryption        |
   |                    | algorithm.                                   |
   +--------------------+----------------------------------------------+

   The client SHOULD use SHA-1, SHA-256, or SHA-512 in preference to MD5
   hashing if it is supported by the CA.

   The server MUST use the texual case specified here, but clients
   SHOULD ignore the textual case when processing this message.  A
   client MUST be able to accept and ignore any unknown keywords that
   might be sent back by a CA.

   If the CA supports none of the above capabilities the SCEP server
   SHOULD return an empty message.  A server MAY simply return an HTTP
   Error.  A client that receives an empty message or an HTTP error
   SHOULD interpret the response as if none of the requested
   capabilities are supported by the CA.

   The Content-type of the reply SHOULD be "text/plain".  Clients SHOULD
   ignore the Content-type, as older server implementations of SCEP may
   send various Content-types.

   Example:
   GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca

   might return:
   GetNextCACert<LF>POSTPKIOperation

   This means that the CA supports the GetNextCACert message and allows
   PKIOperation messages (PKCSreq, GetCert, GetCertInitial, ...) to be
   sent using HTTP POST.