Re: [pkix] Managing Long-Lived CA certs

[Denis <[e-mail]>]

Max,

Just my 1 cent ... since you said you would be interested to hear opinions.

PKI is still very useful and used for servers, but it is no more 
adequate to be used for user authentication over the net.

Initially, privacy was not considered, but now it is. Using PKC for 
users or clients allows to link user accounts between servers
whereas it is not the case with FIDO which has been built using "privacy 
by design" principles. What we need today for human users
is no more only security but *both privacy and security* (where privacy 
comes first).

Coming back to your original proposal, I quote your text below:

    What I am thinking about would be adding an extension that says:
    "This CA can issue certificates from up to 5 years from the validFrom,
    after this, just use it to provide revocation information". This
    might provide some protection in case the CA key is compromised after
    the initial 5 years of validity (e.g., certificates issued after
    that date shall be rejected).

The way you present the case violates one the fundamentals of PKI: A 
certificate contains necessarily a validity period defined by:

Validity ::= SEQUENCE {
notBeforeTime,
notAfterTime }

A CA is not required to handle revocation, once the certificate has expired.

However, before that sentence you wrote:

    Until we have a supported mechanism for reprovisioning devices
    (...), one possible solution for limiting the exposure of the
    private key
    would be to have a scoped certificate issuance period.

Hence you have identified the solution: work on a mechanism for 
reprovisioning devices.

RFC 2510 that was issued in the last century (March 1999) contains a 
description on how to perform a root key change.
See  section "2.4 Root CA key update". This might possibly help to solve 
your problem.

This is just my 1 cent.

Denis

> Max, You are absolutely right.  The "PKI community" (which doesn't 
> really exist) have left PKI to die and the market is therefore 
> flocking around FIDO alliance products
> which unlike PKI were designed for an on-line world from the beginning.
>
> Anders
>
> On 2017-07-19 19:33, Dr. Pala wrote:
>> 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:[e-mail]] *På vegne af *David A. Cooper
>>> *Sendt:* 18 July 2017 16:03
>>> *Til:* Peter Gutmann <[e-mail]>
>>> *Cc:* PKIX <[e-mail]>
>>> *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<[e-mail]> <mailto:[e-mail]>  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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pkix
>>
>> -- 
>> Best Regards,
>> Massimiliano Pala, Ph.D.
>> OpenCA Labs Director
>> OpenCA Logo
>>
>>
>> _______________________________________________
>> pkix mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix