Re: [lamps] Interest to standardize PKI REST APIs?

["Brockhaus, Hendrik" <[e-mail]>]

> Michael Richardson <[e-mail]>  wrote:
> 
> Brockhaus, Hendrik <[e-mail]> wrote:
>     > I think we need to first collect the required certificate management
>     > use cases and check if they are addressed by existing protocols.
> 
> I don't want to do that.  It's boiling the ocean.

IMHO knowing about the uses cases we want to address is not  'boiling the ocean'. If we want to come up with a solution that fits our needs, we should do this. Other vice we come up with a solution that looks nice, but cannot be used for major use cases. Like EST is an interesting approach for the last mile, but does not offer revocation, self-contained messages and end-to-end security. All are required in more complex scenarios.

I see the following requirements.
- Enrollment, update und revocation
- Local and central key generation
- Confirmation of certificate enrollment/update
- Polling for delayed delivery
- Some general messages like GetCSRParam and RootCACertUpadate
- Approval of request by intermediate RAs, e.g. by adding additional signatures
- Security features
  . Self-contained protection of requests/responses (end-to-end security)
  . Proof-of-possession
  . Proof-of-identity, e.g. signature, HMAC
  . Replay protection, e.g. nonces
  . Timeliness, e.g. timestamps

So there is no surprise. But some features like self-contains messages together with approval of an RA is not available in protocols like ACME and EST. So we can discuss extending these, or we utilize an existing protocol like CMP that already offers the above and adapt its transport and messages flow to REST.