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.