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

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

Hi Tomas

I fully understand your pain implementing many different proprietary APIs and I also dislike such proprietary APIs for certificate management. Typically such proprietary APIs or protocols lack the desired security features a certificate management protocol developed by an IETF Security WG offer.
That is the reason to enhance the usability of existing standards like CMP. This may also hold true for the request for RESTful APIs especially from cloud developer.

I think we need to first collect the required certificate management use cases and check if they are addressed by existing protocols.
Then I see two approaches:
- Develop a new certificate management protocol using standard functionality of REST frameworks and learn from or even copy parts from existing protocols. 
- Take an existing certificate management protocol, e.g. CMP, adapt the transport to REST APIs and adapt the transaction concept slightly to allow a state-less server.
As already said, I dislike to develop further certificate management protocols. I think there are enough around already. Therefor I would prefer the second approach. But finally the solution must be acceptable to the target audience of developers asking for REST APIs for certificate management.

Are there also other opinions in the WG?

Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[e-mail]> Im Auftrag von Tomas Gustavsson
> Gesendet: Samstag, 1. Juni 2019 13:54
> An: [e-mail]
> Betreff: [lamps] Interest to standardize PKI REST APIs?
> 
> Hi,
> 
> This is a continuation of a topic that appeared in another thread, that I chose
> to start another thread about to not diverge the original thread. (original
> thread [lamps] Support for working on the lightweight CMP profile). Consider
> this an exploratory discussion.
> 
> - Background:
> Today RESTful APIs are popular due to the simplicity of implementation on
> the client and on the server. I myself has worked with implementation on
> servers and clients for a range of standard APIs (such as SCEP, CMP, EST,
> ACME, PKCS#11 and more). I also find REST APIs engaging to work with as
> you don't need any special client software. If implementing in Java you just
> go at it with the standard API, if scripting you just use curl, etc. You also
> typically get easy to parse error messages back in JSON format. Very nice and
> easy.
> 
> - Benefits of standard APIs
> Using standard APIs you get less lock-in effects. Less lock-in is typically good
> for the whole industry and use base long-term. Using standard APIs an end
> user can replace various components (clients, RA,
> CA) in their system to other vendors if they so desire. We have seen this
> work in practice, replacing CA technology components transparently for the
> rest of the system, quick and cost effective.
> IETF has been very good at producing industry wide standards used across
> multiple verticals.
> 
> - Current REST-like protocols
> In lamps/pkix we have a couple of RESTlike APIs today.
> ACME for enrolling server certificates. A protocol for a specific purpose, but
> gaining popularity due to the easiness of implementing clients (often as
> scripts).
> EST is perhaps not a strict REST API but can be used in a similar form on the
> client side. All you need is openssl and curl to use it from the client side.
> 
> - Current limitations
> In many deployments there are three components: client - RA - CA. EST and
> ACME typically runs on the client-RA side. EST also runs on the RA-CA side in
> simpler use cases. For more complex use cases, where say revocation is also
> needed it's more common to use CMP or a proprietary SOAP or REST API on
> the RA-CA side. Just to make this single point, the current REST-like APIs does
> not have revoke (EST has full-CMC method but that makes it complete non-
> REST-like and harder to implement).
> 
> - Current "full" REST APIs
> Various products have REST APIs. These are proprietary (completely natural
> as there are no standards) and thus clients/RAs/CAs suffer from having to
> implements multiple REST APIs in order to be interoperable with various
> vendors.
> 
> - Probe:
> Do others see the need/interest to standardize a more "full" REST API?
> We see requests and customer interest for REST APIs. Some of the
> requested REST functionality could very well be standardized, while some are
> more product specific and could be harder.
> 
> Do others see the same?
> 
> - Disclosure:
> I work for PrimeKey, a vendor who implements the (open source) CA
> software EJBCA.
> 
> Regards,
> Tomas
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.
> brockhaus%40siemens.com%7Cdf45bd27b9c241677a3a08d6e687d111%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636949868334006281&amp;
> sdata=rUYwh%2BPG4ZIdPzUYSWBOv1OvDb23N7fdHbyUOCup1dw%3D&am
> p;reserved=0