Subject: Re: [lamps] Support for working on the lightweight CMP profile

From: Tomas Gustavsson <[email-masked]>
Date: Sat, 1 Jun 2019 12:30:22 +0200

On 2019-05-31 21:12, Michael Richardson wrote:
> 
> Peylo, Martin (Nokia - FI/Espoo) <[email-masked]> wrote:
>> One should note that the subject of this email seems to be
>> somewhat misleading as it is overly limiting the scope. I expect
>> that besides clarifications for e.g. RA-CA communications, the
>> upcoming work will also include a refresh of mandatory algorithms
>> (bye bye SHA-1). While both of those will certainly be beneficial
>> also for the lightweight CMP on the interface to EEs, it will
>> also have positive influence beyond the "lightweight CMP" scope.
> 
> I think that updating algorithms almost goes without saying, but
> it's good you said it.
> 
>>> Plus we have a bunch of proprietary RESTful interfaces to CAs.
> 
>> As they are proprietary, they seem to be somewhat out of IETF
>> scope and interoperability might not have been your focus when
>> you were creating those?
> 
> The point is, if I have to support a proprietary interface to some
> CA, is there an advantage to also supporting a standard lightweight
> CMP if talking to the CA vendor still requires the proprietary
> RESTful interface.  I am expected one or two of those to become
> defacto specifications, the way the AWS EC2 API did.

You may want to support CMP towards the client, but use the CAs native
API on that side. We've had several customers using CMP where the
benefit has been that they have been able to migrate from one CA
software to another (CA software in our case). By implementing
standard APIs like EST and CMP we bring this forward as a benefit of
less lock-in effects, customers can choose to replace us if they want.
And we have seen this non-lock-in work in reality.

(ps: I am the author of a Certificate Authority software product, just
technology no CA service)

(REST APIs is a very interesting topic and deserve a separate thread
imho. We btw also have ACME as standardizes enrollment protocol for
another subset of functionality. I'll start a separate topic on this.)

> (ps: I am the author of a Registration Authority product)
> 
> -- Michael Richardson <[email-masked]>, Sandelman Software
> Works -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________ Spasm mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Sat, 1 Jun 2019 13:53:37 +0200

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

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 3 Jun 2019 14:36:15 +0000

> Von: Spasm <[email-masked]> Im Auftrag von Michael Richardson
> Gesendet: Freitag, 31. Mai 2019 21:08
> 
> Based upon your comments, I will change my view, and offer support for
> lightweight CMP.
> 

Thanks to Tomas for his good explanation and to Michael for changing his view :-)

Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 7 Jun 2019 17:22:53 +0000

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 <[email-masked]> Im Auftrag von Tomas Gustavsson
> Gesendet: Samstag, 1. Juni 2019 13:54
> An: [email-masked]
> 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.
> 
> 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.
> 
> 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).
> 
> 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:
> requested REST functionality could very well be standardized, while some are
> more product specific and could be harder.
> 
> Do others see the same?
> 
> - Disclosure:
> [email-masked]
> 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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 16:00:12 -0400

Brockhaus, Hendrik <[email-masked]> 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.

I'm okay with making a list of RESTful APIs (proprietary ones, most of them
have public specifications though), if only so that we know who to invite.

    > - Develop a new certificate management protocol using standard
    > functionality of REST frameworks and learn from or even copy parts from
    > existing protocols.

sure, but: https://www.explainxkcd.com/wiki/index.php/927:_Standards

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

I think that this is what we should do.

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

Good, we agree :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tomas Gustavsson <[email-masked]>
Date: Sun, 9 Jun 2019 18:43:26 +0200

On 2019-06-07 22:00, Michael Richardson wrote:
>> I think we need to first collect the required certificate
>> management use cases and check if they are addressed by existing
>> protocols.
> 
> I'm okay with making a list of RESTful APIs (proprietary ones, most
> of them have public specifications though), if only so that we know
> who to invite.
> 
>> 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.
> 
> sure, but:
> https://www.explainxkcd.com/wiki/index.php/927:_Standards
> 
>> - 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.
> 

Thanks for the answers. The current protocol that is most "REST-like"
imho is EST, if not using the "fullcmc" functionality. You can
maneuver it with openssl and curl for the simple methods.
Some often required functions are missing, most notable revocation.

> 
>> 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.
> 
> Good, we agree :-)
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 9 Jun 2019 20:57:55 +0000

Why won't ACME, with perhaps new challenge(s), suffice?

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 10 Jun 2019 07:34:27 +0200

> Why won't ACME, with perhaps new challenge(s), suffice?

Oh, of course, ACME may do the trick, being REST already. ACME having
such a specific target, care has to be taken to not bastardize it.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Jun 2019 12:10:26 +0000

ACME's a framework, and in addition to the base spec which includes DNS hosts, it is already being used for mobile phones, IP addresses, etc.

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 10 Jun 2019 16:18:09 +0200

Are there any examples of such additions to the base spec publicly
available?

On 2019-06-10 14:10, Salz, Rich wrote:
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Jun 2019 15:03:58 +0000

Many.  Look at https://datatracker.ietf.org/wg/acme/documents/ to see the document list; the "authority token" is for phones, the rest should be obvious.

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 10 Jun 2019 17:27:04 +0200

Thanks. Lots of interesting reading there. I was aware of some of the
new validation methods for webPKI (like CAA), but not this for example.
https://datatracker.ietf.org/doc/draft-moriarty-acme-client

Seems like there is indeed some good work done. I'll continue monitoring
that.

Cheers,
Tomas

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 12 Jun 2019 05:49:46 +0000

> Michael Richardson <[email-masked]>  wrote:
> 

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.

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 12 Jun 2019 08:43:57 +0200

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

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 12 Jun 2019 08:43:44 +0000

> Tomas Gustavsson <[email-masked]> 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).
> 

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

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 12 Jun 2019 12:29:55 +0000

>    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 u…

Adding this kind of thing to ACME, as a new challenge and response, is very straightforward.

Also, look at the ACME "STAR" documents which handle RA-like delegation.

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 12 Jun 2019 12:18:02 -0600

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

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 13 Jun 2019 08:45:00 +0200

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

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

>>> ..ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.