[Pki-devel] [rhcs-dev-list] latest restful interface doc

[Jack Magne]

On 10/18/2011 02:44 PM, Ade Lee wrote:
> Based on discussions with jmagne and ayoung, here is the latest version.
> Please feel free to comment!
>
> ayoung will post to wiki.
>
> Ade
>
>    
Ade:

A few questions:

1. I see that for the ocsp service we have something like this:

"GET" 	"/pki/certificate/ocsp" 	"Get OCSP response"



I see that perhaps we are trying to first get to the certificate in 
question and then drill down into the ocsp status of said certificate.

Question is, is it not true that OCSP responders respond to a common 
format (so any client can connect) as explained here:

A.1.1 Request

    HTTP based OCSP requests can use either the GET or the POST method to
    submit their requests. To enable HTTP caching, small requests (that
    after encoding are less than 255 bytes), MAY be submitted using GET.
    If HTTP caching is not important, or the request is greater than 255
    bytes, the request SHOULD be submitted using POST.  Where privacy is
    a requirement, OCSP transactions exchanged using HTTP MAY be
    protected using either TLS/SSL or some other lower layer protocol.

    An OCSP request using the GET method is constructed as follows:

    GET {url}/{url-encoding of base-64 encoding of the DER encoding of
    the OCSPRequest}

    where {url} may be derived from the value of AuthorityInfoAccess or
    other local configuration of the OCSP client.

    An OCSP request using the POST method is constructed as follows: The
    Content-Type header has the value "application/ocsp-request" while
    the body of the message is the binary value of the DER encoding of
    the OCSPRequest.

I wonder if instead of drilling down to a cert and proceeding, it would make more sense to have a top level url ending with perhaps "ocsp", that is then passed the
certificate info in the standard way? I don't know if this is in fact restful.

2. I was curious as to what the following does:







	"PUT" 	"/pki/certificate" 	"Add a certificate" 	"None",,,

Is this actually for submitting a certificate request? I realize there is a section below dealing with requests.
Is this perhaps something that is referenced by some other piece of the server itself? Like approving a request would trigger this?

3. I notice proceeding below there is a whole section devoted to profiles. I assume the bulk of the requests are agent and adminy type actions in managing profiles.
I was just wondering if we have a handle on how to actually USE a profile, that is have the standalone client be able to apply for a certificate using one of these profiles we have?


Is it absorbed into the act of creating "requests" further down into the API? One of the payload params would be a profile? Or perhaps a portion of the url itself would be
for the profile used?



4. Also in some of the online doco they express the requests with 
possibly some sort of templated param at the end like this: GET 
pki/certificate/{cert_serial_no} or some such. Is this convention kind 
of implied by the API or would it be filled in later?


Looks like it is shaping up as we continue to discuss.

thanks,
jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20111018/762c7350/attachment.htm>