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

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

> Tomas Gustavsson <[e-mail]> wrote: 
> 
> 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.

I do not feel that this contradicts with self-contained message protection. At least integrity protection should work, or am I wrong?

> 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.

A CMP rr message is a self-contained revocation message. Isn't it similar to PKCS#10, certificate and CRL? May be it needs to be adapted or tailored. 

> 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.

Agree. That is why I like to define the use cases first :-)

Most simple use case require a trusted first hop. For many scenarios this assumption does not hold true. That is why I would like to have some end-to-end integrity protection.
In a lot of industrial environments messages need to be transported in a store-and-forward fashion due to network separation or required explicit admin approval. That is why I like self-contained message integrity protection.

Hendrik

> 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.