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

["Dr. Pala" <[e-mail]>]

Hi Tomas, all,

I have not followed all the thread - however, it seems to me we already 
have what is being proposed. ACME is a web-oriented protocol that works 
for low-volume/low-efficiency issuance of certificates and works well 
for the Web PKI(s). Similarly, CMP and CMS allow for full management of 
credentials (although they require the client to be know what type of 
credentials are needed on the device).

One thing I do not like about ACME and EST in particular (and probably 
about what you are proposing here), it is their dependency on the 
transport protocol - this is usually a very bad idea that prevents 
abstracting from the specific transport media, therefore limiting your 
options and require IP connectivity.

 From this point of view, I do not really see the need to define "yet 
another HTTP-based way to transfer the same information" - ACME already 
duplicated so much of the work we already have done 20 years ago with no 
relevant benefits besides being more inefficient, lacking all the more 
traditional controls, and not providing much benefits from an automation 
standpoint.

Let's try to avoid doing the same mistake again :D

I also would like to draw your attention on some work that is going on 
in some other WGs. In particular, we are working in the EMU WG to 
provide a EAP-Based method for credentials management (EAP-CREDS 
currently NOT a WG document, but we hope it will be adopted - 
https://datatracker.ietf.org/doc/draft-pala-eap-creds/) - you might find 
some inspiration for ideas there - we provide a minimal protocol for 
handling different types of secrets and the possibility to encapsulate 
your own protocol (e.g., an existing one like CMP or a proprietary one). 
Maybe this approach might inspire some further ideas in case you still 
want to pursue :D

Last but not least, I think that if any standardization is needed 
(instead of "yet another API to do the same thing") is in the 
/*interface to your Cryptographic API*/. This is, I think, much more 
interesting (and needed).

Today, I think, one of the main issue we have is to be able to integrate 
crypto libraries and being able to switch across platforms. Especially 
if you work in a application-level layer (maybe with JS or another 
interpreted language), you might have noticed that the support for the 
security primitives (and advanced functionalities) is not very well 
implemented. Moreover, porting to a different Crypto Service Provider is 
usually a nightmare...

Why not working on a Standard API for Cryptographic Libraries instead ? 
Similarly to what we did for LDAP, this could provide the portability 
for applications (and programming frameworks) that we really need. We 
started a Mailing List sometime ago - but did not have the time to move 
forward with real work. If you are interested, please let me know.

Just my 2 cents....

Cheers,
Max

P.S.: Last thing - as soon as we are done updating the CMS interface in 
LibPKI we will probably add support for either CMP or CMC. Maybe this is 
also relevant to your effort... :D

On 6/7/19 11:22 AM, Brockhaus, Hendrik wrote:
> 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
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo