Hi,
Excerpts from Paul Berry's message of Fri Sep 17 14:12:54 -0400 2010:
> I'm feeling unsettled about Mathias's proposal, for a couple of reasons:
>
> 1. It relies on some indirector features that we don't currently support
> (410 errors, head requests, post requests, more richly detailed http error
> messages, richer support of "accept" headers, and find requests with no
> key). Granted, some of these features would be nice to add, but I'm not
> sure it makes sense to do them just so that we can make the REST API for
> cert signing take this form.
>
I totally agree with you. I've outlined a proposal that may be
complicated to implement due to technical limitation of the current
puppet code.
I've mainly approached that from an API perspective - not knowing much
about the implementation details.
> 2. It puts a bigger burden than I would like to put on clients of the REST
> API to understand how the certificate system works. In my original
> proposal, if a client wanted to know the status of a hostname, they would
> issue a single request and get the status back in an intuitive format. If
> we go with Mathias's suggestions, the client has to issue several related
> requests and synthesize the result. If the client gets this wrong, they may
> falsely conclude that a certificate is valid when it isn't, and that could
> lead to a lot of customer confusion.
Well - I depends what you'd like to do with the state. For the example
above, asking if a certificate is valid is:
1. HEAD https://<master>/<environment>/certificate/<cert_name>
200 Ok --> means the certificate is valid
Other possible status are:
404 Not found --> means the certificate doesn't exist
410 Gone --> means the certificate is revoked.
What could be added here is a custom status that says there is csr
waiting for <cert_name>:
499 Requested
> By having a specific REST call to
> query the status of a cert (analogous to "puppet cert --verify") we make
> sure it is our code that is determining the validity, so we can be sure to
> do it right.
>
Right - I also pondered that issue. Now that I think of it the REST API
could modified as follow:
> > <state> is one of:
> > - 'requested' if the host has sent the server a certificate request
> > but no certificate has been issued.
1. Http request:
HEAD https://<master>/<environment>/certificate_request/<cert_name>
Http response:
200 OK
With the addition that when the certificate has been issued (ie the csr
has been process) the Http status code should be "410 Gone":
1. Http request:
HEAD https://<master>/<environment>/certificate_request/<issued_cert_name>
Http response:
410 Gone
> On Fri, Sep 17, 2010 at 10:35 AM, Luke Kanies <[email protected]> wrote:
>
> > I like Mathias's proposal, and I think all it leaves to solve is signing of
> > certs, right?
> >
This is done by a POST request:
1. Http request:
POST https://<master>/<environment>/certificate/
<cert_name>
<<< Server side processing: generate the certificate >>>
Http response:
201 OK
Location: https://<master>/<environment>/certificate/<cert_name>
https://<master>/<environment>/certificate/<cert_name>
A side effect of the POST request would be to mark the csr as processed
(thus being able to return 410 Gone instead of 200 OK).
--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
