Re: [pkix] Managing Long-Lived CA certs
"Dr. Pala" <director@openca.org> Wed, 19 July 2017 17:33 UTC
Return-Path: <director@openca.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFC212EC36 for <pkix@ietfa.amsl.com>; Wed, 19 Jul 2017 10:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95-Yo5_ibpjx for <pkix@ietfa.amsl.com>; Wed, 19 Jul 2017 10:33:41 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1AC129AF9 for <pkix@ietf.org>; Wed, 19 Jul 2017 10:33:41 -0700 (PDT)
Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 5161D3740F19 for <pkix@ietf.org>; Wed, 19 Jul 2017 13:33:40 -0400 (EDT)
To: pkix@ietf.org
References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <d032d03f-6ece-44e1-58b7-e3141f3b8e3d@openca.org>
Date: Wed, 19 Jul 2017 19:33:37 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <003d01d2ffdd$35d67c70$a1837550$@x500.eu>
Content-Type: multipart/alternative; boundary="------------CD03AC28C45A5373AEF99608"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/2eF_U3rWn7ESq00nyHGODSY8oTQ>
Subject: Re: [pkix] Managing Long-Lived CA certs
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 17:33:44 -0000
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:pkix-bounces@ietf.org] *På vegne af *David A. Cooper > *Sendt:* 18 July 2017 16:03 > *Til:* Peter Gutmann <pgut001@cs.auckland.ac.nz> > *Cc:* PKIX <pkix@ietf.org> > *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<era@x500.eu> <mailto:era@x500.eu> 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 > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo
- Re: [pkix] Managing Long-Lived CA certs Dr. Pala
- [pkix] Managing Long-Lived CA certs Dr. Pala
- Re: [pkix] Managing Long-Lived CA certs Rob Stradling
- Re: [pkix] Managing Long-Lived CA certs Dr. Pala
- Re: [pkix] Managing Long-Lived CA certs Erik Andersen
- Re: [pkix] Managing Long-Lived CA certs Dr. Pala
- Re: [pkix] Managing Long-Lived CA certs Erik Andersen
- Re: [pkix] Managing Long-Lived CA certs Carl Wallace
- Re: [pkix] Managing Long-Lived CA certs Dr. Pala
- Re: [pkix] Managing Long-Lived CA certs Santosh Chokhani
- Re: [pkix] Managing Long-Lived CA certs Carl Wallace
- Re: [pkix] Managing Long-Lived CA certs Dr. Pala
- Re: [pkix] Managing Long-Lived CA certs Peter Gutmann
- Re: [pkix] Managing Long-Lived CA certs Erik Andersen
- Re: [pkix] Managing Long-Lived CA certs David A. Cooper
- Re: [pkix] Managing Long-Lived CA certs Peter Gutmann
- Re: [pkix] Managing Long-Lived CA certs David A. Cooper
- Re: [pkix] Managing Long-Lived CA certs Peter Gutmann
- Re: [pkix] Managing Long-Lived CA certs Erik Andersen
- Re: [pkix] Managing Long-Lived CA certs swilson
- Re: [pkix] Managing Long-Lived CA certs Dr. Pala
- Re: [pkix] Managing Long-Lived CA certs Anders Rundgren
- Re: [pkix] Managing Long-Lived CA certs Denis
- Re: [pkix] Managing Long-Lived CA certs Carl Wallace
- Re: [pkix] Managing Long-Lived CA certs EG Giessmann
- Re: [pkix] Managing Long-Lived CA certs Dr. Pala
- Re: [pkix] Managing Long-Lived CA certs Dr. Pala
- [pkix] Upgradable/Replaceable IoT systems. Re: Ma… Anders Rundgren
- [pkix] Connected Cars. Upgradable/Replaceable IoT… Anders Rundgren
- Re: [pkix] Connected Cars. Upgradable/Replaceable… Robert Moskowitz
- Re: [pkix] Connected Cars. Upgradable/Replaceable… Peter Gutmann
- Re: [pkix] Connected Cars. Upgradable/Replaceable… Robert Moskowitz
- Re: [pkix] Connected Cars. Upgradable/Replaceable… Erwann Abalea