Re: Managing Long-Lived CA certs

Hi all,

I just want to point out that the extension that is mentioned is NOT the 
same as I wanted try to propose (if this is highly controversial, it can 
just be an informational RFC). The only correct answer to my question 
actually is: nothing like that exists, something similar was deprecated 
in RFC5280 but it is still used in other environments.

What follows is a bit of summary of (a) what I see happening in the real 
world, and (b) my PERSONAL point of view about the real situation where 
we are heading today.

As Erik pointed out, my quick and short proposal is an attempt to 
address some shortcomings that I see happening especially in the IoT / 
Device world where expertise around certificates and PKIs is just not there.

More and more people that do not really understand the way PKIs SHOULD 
work in order to really address the threats related to Key Management 
propose the use of weak infrastructure just because (a) there is no 
active work aimed at solving issues that exists and (b) go for a quick 
solution that provides, in many cases, really just a fuzzy feeling 
rather than solid architectures.

An example of this is the trend that has been growing a lot at IETF with 
the insanity about short-lived certificates (different working groups 
have no other choices but use what other WG did without realizing how 
weak those solutions are). I can not find any proposals in the recent 
times that does not say "let's use short-lived certificates": did we all 
became great at protecting secrets ? do we all use HW protected keys ?

In my experience I have seen (positively) increasing the use of crypto 
and keys with a decreasing understanding about the risks and less 
options when it comes to recover from broken trust.

Also, the same people that argue for short-lived certificates often pick 
that option because of the (proven wrong over and over again) 
willingness to mix AuthN and AuthZ - most of the times not even 
understanding that that is what the authors are doing!

PKIX has a long history about trying to separate the two concepts (i.e., 
using tokens for authorization like attribute certificates). Delegation, 
especially when it is a self-delegation, was solved with the 
introduction of proxy certificates.

I also would like to point out the inability (or, actually more 
accurately the un-willingness - especially from former ADs) to take on 
important work and new proposals that address efficient revocation 
handling and discoverability of PK-related services (hack, we still not 
have a distributed support system for Public Key operations deployed or 
even envisioned in 2017! That is simply CRAZY to me!).

We are still stuck with CRLs most of the times, OCSP if we are lucky, 
and in most cases even these mechanisms are criticized widely by people 
at the meetings without really understanding that Internet PKI and PKIs 
(as pointed out) are not the same thing. Even in the Internet PKIs, 
applications like browsers do not properly check revocation claiming 
that few milliseconds of delay (well, they could just check it in 
parallel and just block further operations in case revocation is 
detected or, as they do for content, they could simply pre-fetch the 
information for usually visited resources).

Wrongly designed PKIs (or Weak PKIs) are being deployed today and 
expected to run for 30yrs when the algorithms that are supported (mainly 
in HW) are NOT going to pass the test of time - not on that scale, not 
for millions of people, not with devices that might handle our private 
data. This will affect our homes and the quality of Internet connections 
(degrading the user experience and creating huge issues for the 
operators in the future).

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 the 
PKI discussions):

  * *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) and now expertise about the nuances of
    understanding and running PKIs is mostly lost or very difficult to
    chase.

  * *The LAMPS WG has, on purpose, a very limited Charter and only few
    items* (mostly quite marginal, I would say) are actually accepted as
    working items. Solving revocation should be the 1st item and the
    most important on the list... but it is not - actually when I
    proposed, it was not even acknowledged.

  * *The constant**nonsense of people saying that PKIs do not work as an
    excuse not to improve them while they are the reason we can deploy
    and manage security and provide privacy. *Eroding all the good work
    done in the past just because people do not understand the
    importance of providing BETTER support for Trust Management rather
    than a QUICK solution (e.g., short-lived certificates, mix of
    authorization and authentication, forgetting the existence of RFCs
    that already provide more secure solutions than the ones that are
    re-invented, today, over and over again).

Things are happening in other environments and lacking the support from 
IETF is really scary. The world moves forward and the IETF is standing 
still on this topic. I really do not understand why.

For example: what is more important, fixing internationalization for 
e-mail addresses or allowing the checking of revocation information in 
such a way that we can restrict the use of short-lived certificates only 
when STRICTLY necessary ?

Well.. things to consider.

I tried many times to push the issue without success... politics is the 
enemy of the right thing to do... and today we are just dealing with 
politicians when it comes to PKIs...

Just my 2 cents.. but I would be interested in your opinions too...

Cheers,
Max


On 7/18/17 5:47 PM, Erik Andersen wrote:
>
> Hi David,
>
> PKIX is not the whole world.
>
> The smart grid security work within IEC TC57 WG15 does not refer to 
> RFC 5280, but only to X.509. X.509 provides functionality, like 
> authorization and validation lists (AVLs) not part  of any IETF 
> specification.
>
> In the smart grid and IoT world, traditional PKI techniques fall 
> short. I believe that is what Max is trying to tell.
>
> Erik
>
> *Fra:*pkix [mailto:[email protected]] *På vegne af *David A. Cooper
> *Sendt:* 18 July 2017 16:03
> *Til:* Peter Gutmann <[email protected]>
> *Cc:* PKIX <[email protected]>
> *Emne:* Re: [pkix] Managing Long-Lived CA certs
>
> Can you provide a citation for your claim that "PKIX says you're not 
> allowed to use it. No reason given, you just can't."?
>
> RFC 5280 says:
>
>     This specification obsoletes [RFC3280].  Differences from RFC 3280
>     are summarized below:
>
>           * Section 4.2.1.4 in RFC 3280, which specified the
>             privateKeyUsagePeriod certificate extension but deprecated its
>             use, was removed.  Use of this ISO standard extension is
>     neither
>             deprecated nor recommended for use in the Internet PKI.
>
> "Use of this ISO standard extension is neither deprecated nor 
> recommended" doesn't sound like "you just can't" to me.
>
> On 07/17/2017 11:31 PM, Peter Gutmann wrote:
>
>     Erik Andersen<[email protected]> <mailto:[email protected]>  writes:
>
>         What about the private key usage period extension
>
>     That would be the obvious choice, but PKIX says you're not allowed to use it.
>
>     No reason given, you just can't.  This would imply that support for it in
>
>     implementations is going to be hard to find...
>
>     Peter.
>
>
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix

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

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix