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

[Tomas Gustavsson <[e-mail]>]

On 2019-06-12 20:18, Dr. Pala wrote:
> 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 think it's about using the right tool for the right jobs, and a full
toolbox is needed :-)

Simply looking at the usage of ACME I think it's clear that it does
provide some standardization benefits, for this/these use cases.
Otherwise we would not see the quick uptake and use I believe. So some
benefits there must be.
There will be many REST APIs created, within IETF or not. With a little
luck there may be some harmonization driven by market needs.

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

All platforms/OS/programming languages have their standards. This will
be hard to sell.
Something that would be very useful (from my usage) is a new standard
API for HSMs. PKCS#11 have been ruling this area for decades, but large
fragmentation is happening now (let's hope a bit on PKCS#11 v3). Also
not a topic I want to spend the rest of my days on though, it will be a
lengthy process and a tough sale...


> 
> 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
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>