HTTP usage

[martinthomson]

Could be significantly better. It would require some fairly major structural changes though.

[martinthomson]

Example: type: "defer" is better replicated with a 503 + Retry-After

[bifurcation]

After thinking about this for a while, I think this is good idea. A sketch of a refactor is below. A PR will be a little longer in coming.

The server manages the following resources:

• Domain validations, representing a challenge/response process
• Domain authorizations, encoding a public key's authority for a domain
• Certificates, with associated metadata (e.g., revocation state, suggested chain)
• A "new authorization resource" resource
• A "new certificate resource" endpoint
• Changes to resources (e.g., providing response to a challenge) are sent in POST requests
• All client-server messages (in POST requests) are encapsulated in JWS under the authorized key
  • No explicit PoP of the authorized key in the protocol
• Resource content is not secret, so GET requests require no authentication/authorization

The authorization flow would something like the following:

• Client POSTs requested authz data to the NewAuthz resource
• NewAuthz creates a new pending authz resource (with its own URI), returns it
  • Authz resource contains validation challenges with their own URIs
• Client POSTs a response to one of the validation resources
• CA validates challenge responses, updates validation and authz resources
  • Marks challenges completed / errored
  • Adds new challenges if necessary
• If validation is complete, authz resource is marked final
  • Maybe turn into a JWT or something at this point
  • Client GETs authz resource to check state

The issuance flow would something like the following:

• Client POSTs requested cert data + authz URI(s) to the NewCert resource
• NewCert checks authorization, and if authorized, returns cert resource (with its own URI)
• Client GETs cert URI (server uses something like 503 if it needs more time)

Other:

• Renewal: Client just GETs cert URI again
• Revocation: Client POSTs revocation request to cert URI

[ravisorg]

Perhaps...

Revocation: Client DELETEs cert URI

[bifurcation]

Revocation: Client DELETEs cert URI

I had considered this, but you really want revocation to be authenticated (so that I can't revoke my competitor's certs). It's not obvious to me how you would authenticate a DELETE request, but a POST can have a signed body.

[martinthomson]

In this case, without a new auth scheme, what Richard says is probably the best approach. The only drawback is that that POST isn't obviously idempotent, but that's actually a feature in sine senses (no replay, resources stay).

[ravisorg]

Agreed. Personally I like to see authentication information separated from the request (eg: in the headers) but that would require some pretty significant structural changes. Assuming that's not going to be done (at least for version 1) then POST makes most sense.

[benburwell]

In the vein of adding a 503 status to defer responses, we might also consider:

• Giving error:malformed a 400 Bad Request status
• Giving error:unauthorized a 401 Unauthorized status
• Giving error:serverInternal a 500 Internal Server Error status
• Giving error:notSupported a 501 Not Implemented status
• Giving error:unknown a 404 Not Found status
• Giving error:badCSR a 422 Unprocessable Entity