Re: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs

Robert Moskowitz <rgm-sec@htt-consult.com> Mon, 24 July 2017 14:11 UTC

Return-Path: <rgm-sec@htt-consult.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 C2E12131D1E for <pkix@ietfa.amsl.com>; Mon, 24 Jul 2017 07:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 sTIzW_7Op-eJ for <pkix@ietfa.amsl.com>; Mon, 24 Jul 2017 07:11:36 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35376131D21 for <pkix@ietf.org>; Mon, 24 Jul 2017 07:11:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1662062192; Mon, 24 Jul 2017 10:11:34 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id c18oskYirEJk; Mon, 24 Jul 2017 10:11:29 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3972562191; Mon, 24 Jul 2017 10:11:29 -0400 (EDT)
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Anders Rundgren <anders.rundgren.net@gmail.com>, "pkix@ietf.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> <c66ebeda-21be-93fe-f315-7d1e7f069505@gmail.com> <b474e62e-64d3-5c9f-6dc3-4f96749f5440@free.fr> <f59e8121-7b66-a6bb-2b31-16a1aeaeaf37@gmail.com> <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com> <07553cee-882a-74e3-569f-2c501461f2dd@htt-consult.com> <1500904462997.1000@cs.auckland.ac.nz>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <b42662de-f1ea-2a3d-6496-e72c9403ba8d@htt-consult.com>
Date: Mon, 24 Jul 2017 10:11:26 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1500904462997.1000@cs.auckland.ac.nz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/Nkp8uWAySfxX4sEF5NLYr1KqGLo>
Subject: Re: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: 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: Mon, 24 Jul 2017 14:11:38 -0000


On 07/24/2017 09:54 AM, Peter Gutmann wrote:
> Robert Moskowitz <rgm-sec@htt-consult.com> writes:
>
>> The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster' PKI
>> with certificate management.  To put it mildly.
> Not just a monster PKI, a monster in general.  They invented their own
> gratuitously incompatible way of doing everything possible (message security,
> certificates, you name it, including a pile of novel security mechanisms never
> before deployed at any real-world scale).
>
> The thing with X.509, CMS, PGP, whatever you want to use is that after about
> twenty years of public naming and shaming vendors have got at least some of
> the bits right (but see for example the thread currently running on mozilla-
> dev about CAs all over the world issuing certs for domain names that can't be
> validated, in other words that were never checked by the CA before the certs
> were issued).
>
> OTOH the 1609.2 stuff, which goes way beyond what any standard public CA has
> ever attempted (e.g. SCMS or Secure Credential Management System, which is...
> no, it's too horrible to go into) will be used in a closed, non-public
> environment where little if anything will ever be tested or checked for
> correctness.
>
> Until the Black Hat and Defcon presentations start appearing...
>
>> I worked on three telematics certificate systems.
> I got exposed to 1609.2.  My response was that there simply wasn't enough
> money in existence to get me to try and make that thing work.

I made a counter proposal which was rejected becuase it was a change in 
direction.  So I saw that the horses had already left the barn and just 
sit back and watch.

And this may be the largest scale ever attempted.  I don't know of any 
PKI with more than 100M entities enrolled.  Though some of the national 
ID systems are in this size.

But hopefully we are not talking 1609.2; I only mentioned it for some 
level of completeness in the automotive environment.