[pkix] Considerations about the need to resume PKIX work

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

[ Cross-Post: LAMS and SAAG ]


Hi all,

I would like to draw the Sec Area attention on an issue that I think is 
becoming more relevant every day.

It seems quite clear that today there is a lot of work around 
authentication and encryption that make use of PKIX certificates. 
However, there is no place in IETF, today, where problems related to 
PKIX can be effectively tackled. In the following paragraphs I try to 
summarize the issue and the proposed work and a call for discussion 
around the feasibility of resuming the work in two particular areas: 
revocation and discoverability.

*The Problem

*What I noticed in recent proposals in many working groups (when it 
comes to certificate management) is that more and more people turn 
towards the use of short-lived certificates to avoid checking revocation 
information. Sometimes this choice is motivated by real technical 
considerations, but in many cases the choice is "forced" because nobody 
is currently working on fixing the two main issues related to trust 
infrastructures: efficient revocation and discoverability of services.

*The Revocation Situation*

Most of the times, when interacting with PKIs, we are still stuck with 
CRLs, OCSP if we are lucky (including stapling - available in TLS 
connections if really really lucky), and in most cases even these 
mechanisms are criticized widely by people as being inadequate today. 
This resulted in applications to use proprietary methods for checking 
revocation (e.g., CRLSet) or to skip checking all together (or mandate 
for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, 
the generation of new keys require (a) a lot of resources, and (b) a 
good source of randomness. Requiring apps / devices to generate new keys 
might seem a good idea at first, but is this better than checking 
revocation ? What about the complexity of key management ?

/Examples of possible work to address the issues are OCSP over DNS and 
some more efficient ways to verify the validity of a whole chain of 
certificates efficiently./

*The Discoverability Situation*

As far as I know, there are no standardized mechanisms that would 
provide discoverability of services that would help users and 
applications to discover Public Key Services providers and associated 
services in a dynamic fashion. When I brought it up during the BoFs of 
possible working groups where the issue could be discussed.. well, the 
proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of 
infrastructure that would facilitate interacting with PKIs ? After all, 
PKIs are the core Trust mechanism that enables reliable authentication 
and encryption over the Internet today. Such infrastructure could really 
improve the security of the Internet and make PKIs more usable from an 
application (and users) standpoint of view.

/Examples of possible work to address the issue are a PKI Resource Query 
Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms 
for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 
0-configuration support for PK)./

*Deployment Trends in the Real World*

Today I am witnessing the deployment of arguably not-well-designed PKIs 
(or, in other terms, what I call Weak PKIs) that do not provide support 
for revocation and that are expected to use CAs and EE certificates with 
validity periods of 30, 35, or 50 years (yes, also EE - especially for 
devices). Besides the fact that it is a common assumption that the 
algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT 
going to pass the test of time, ignoring the revocation could really 
affect the privacy of millions of people - and we are currently not 
doing anything at the IETF to prevent this issue.

/There is the need for simple revocation services, but arguably we do 
not have what's needed today (requires improvements)./

*IETF Specific Situation and Issues*

Why are we so unprepared to face these issues ? I would say (still 
personal point of view - based on almost 20 yrs of participation in PKI 
discussions) that these might be some of the main reasons:

  * *There are NO venues where to discuss possible solutions to existing
    problems.* The PKIX working group has been closed down (very
    arbitrarily, I might say, since there is still a lot of work needed
    to be done around PKIX as highlighted above)

  * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very
    narrow scoped Charters and only few items**(mostly quite marginal
    issues, IMO) are actually accepted as working items (w/ reference to
    SPASM and LAMPS in particular).* Solving revocation and
    discoverability issues should be the 1st item and the most important
    on the list (at least revocation) but they are not - actually when
    that was proposed to be included as part of the charter(s), the
    requests were not even acknowledged or rejected with no real
    technical reasons.

  * *The constant**nonsense of people saying that PKIs do not work as an
    excuse not to improve them while they (PKIs) are the reason we can
    deploy secure protocols and provide privacy. *It is evident that
    PKIs are here to stay, this is a fact. Their usage has increased
    exponentially in the past years and they have, so far, passed the
    test of time. IoT is one use-case. ANIMA is another. ACME is
    another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 
Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on 
these problems is really scary to me. The world moves forward, fast, and 
the IETF is standing still on this topic./*I really do not understand why.*/

*Final Considerations*

In this message I try to summarize the reasons why I think there is the 
need to provide a venue where these problems are discussed and the need 
for key people to not actively block the possibility for people that are 
willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to 
understand what the position of the whole security area is around these 
points and the proposed work.

/I hope that the discussion around this message can spark some interest 
and that work in the PKIX area can finally resume at the IETF - which 
was, in the past, thought of as the lighthouse where these issues could 
be addressed./

A small request, please, try to read this e-mail carefully and consider 
the implications of NOT taking on these tasks when replying and/or 
discussing the topic. Also, since I know this (PKIX) is a minefield for 
"political" reasons (which should not be a drive here), please keep the 
discussion on the positive / constructive side (thanks).

/If you feel like a private response is better than on the mailing list, 
please just reply privately./

Looking forward to hear your opinions on this hoping that this e-mail 
can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

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