Re: [pkix] Managing Long-Lived CA certs

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 19 July 2017 17:49 UTC

Return-Path: <anders.rundgren.net@gmail.com>
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 BC437131B67 for <pkix@ietfa.amsl.com>; Wed, 19 Jul 2017 10:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5ycvMLURY1Po for <pkix@ietfa.amsl.com>; Wed, 19 Jul 2017 10:49:48 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0053B1317BE for <pkix@ietf.org>; Wed, 19 Jul 2017 10:49:47 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id k69so5385845wmc.1 for <pkix@ietf.org>; Wed, 19 Jul 2017 10:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=BWRvfjSee6feYq++WUExVk5z7GgF4zWcTsaoM33MZeo=; b=fOD+iN5MdvmKEoz3u7EhNZHUOQMCcT0vkFzosaUd6nL/718zNDu7VdolFBV9oGgyGQ hkH2jQCRzQhK3M40jxiOI46l7LxXd2C97ydwQxBCIy2v0dzOKUjssISqzf9LMFK80ZuK L04L30ztEw3l91ZZpeoIXXTCoZDAej/ZKvJeK6edRsT8YY8wOtG9Nse79S/Lj0hQFYvN 0IWF8RHy2T8XvC76w6QzuJeDvKIsk3oHrQx3D70TOuXi7CbvE3CVONGfG2xX9brAUJrD zLpvP6u5nS8QOxPG/HonUdx8DbJ/oi0p4xea1x+96KDvMb/mJfF0/xoy8OWhsotPnPRs TraQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BWRvfjSee6feYq++WUExVk5z7GgF4zWcTsaoM33MZeo=; b=ODl2QipQO6fenqYqn+ZFi6McJT7LCVsUN7nAJ+nwv1rDvRIElLTBHPJIu7NIMkcJI9 Fkmw4C9CiRtQon0m7yHfkNSvIujXhMTMqepGvRWWOk6SPy42YctAeG1Dj7oDskQljTIw f7udC8n5QcER6f1ipG+N7HlY1F3+Q0+Gvt+J0LDBMJdX9+UtisuQFxEGzuV6Wq90mWmQ /UMySKCLRB49P+suJALZjxwaosiBGbkxAdkLEnz7zJkyazmIoIXXowoLFzi3YoW9kOQb G4y6A9Orq9s4+Qf6IoEODV6T15W7aK9hUycSXv6o2oYdc6YPjnIOmGJ2N+I+WUT3fmFy fJfw==
X-Gm-Message-State: AIVw111ZpM8oHsLHuelv5PKimBkR6z7upoEHkQWV6B1+hoGQ/R38gskZ 5a7TCMrcSc1dQcFV
X-Received: by 10.28.189.214 with SMTP id n205mr542450wmf.122.1500486586145; Wed, 19 Jul 2017 10:49:46 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id n205sm398084wmf.21.2017.07.19.10.49.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 10:49:45 -0700 (PDT)
To: "Dr. Pala" <director@openca.org>, 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> <d032d03f-6ece-44e1-58b7-e3141f3b8e3d@openca.org>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <c66ebeda-21be-93fe-f315-7d1e7f069505@gmail.com>
Date: Wed, 19 Jul 2017 19:49:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <d032d03f-6ece-44e1-58b7-e3141f3b8e3d@openca.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/CFZ1AxA0cSgTmM8oklBKiuQtv24>
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:49:51 -0000

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: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
> 
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>