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

[Tomas Gustavsson <[e-mail]>]

I'm not sure that properties such as self-contained protection is a good
fit for REST API. (one of) The key point (at least for me) of REST API
is the easiness of testing/development. You can use a Swagger web page
to test the API directly from a browser, and get copy-paste curl
commands to run in a script. Error responses are simple, human readable
JSON.
Using CMP, for example, as base will not make this possible. CMP works
well as it is imho, and I don't think it will become easier to use with
a new transport. The HTTP transport itself of CMP is easy enough (I like
it).

Of course PKCS#10 request and certificates/CRLs are self-contained
protected, but there is nothing similar for say revocation requests.

Simple use cases can use simple protocols, but it will be hard I think
to support complex use cases sẃith such. This is where CMP shines, for
complex use cases, and I have no ambition to replace CMP.

Regards,
Tomas

On 2019-06-12 07:49, Brockhaus, Hendrik wrote:
>> 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.
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>