Re: [lamps] rollover of CA

Eliot Lear <lear@lear.ch> Fri, 03 September 2021 12:56 UTC

Return-Path: <lear@lear.ch>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58993A1D5E for <spasm@ietfa.amsl.com>; Fri, 3 Sep 2021 05:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.79
X-Spam-Level:
X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 jfm3FAfwS23M for <spasm@ietfa.amsl.com>; Fri, 3 Sep 2021 05:56:48 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 6E7DC3A1D7E for <spasm@ietf.org>; Fri, 3 Sep 2021 05:56:48 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::7] ([IPv6:2001:420:c0c0:1011:0:0:0:7]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 183CubBI161549 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 3 Sep 2021 14:56:38 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630673800; bh=cEt6ru2V7M02+sASJCm9BfgS/dwzWlqSy4Uz9qX/4ao=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Y+4iMcUdsWDubJs16hujEjTNG4FS3g3cktTPxm44LJegIE3ihq2NqLfmPSVKw4VOg qdZZMvkSmuzachAmQlCxfYpe+UnM3iap+vJQDIWG1s7eDRPcqz4+dGzlaljWzaxwR6 hcSzsgLqv7x4sFFjV4AKeL4Sg/AKUDfVYD4BM+ug=
To: "Brown, Wendy (10421)" <wendy.brown=40protiviti.com@dmarc.ietf.org>, Tomas Gustavsson <tomas.gustavsson@primekey.com>, Deb Cooley <debcooley1@gmail.com>, Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: SPASM <spasm@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
References: <17240.1630591789@localhost> <CAErg=HH9o8wXgo9RS0GDrn6ZgL7TD3TF25PiUNW7XePML7252w@mail.gmail.com> <CAGgd1Odk-xVmYb8-i-1pCv-n=oeFCnjt-xsCC9mqvGowaLpeZg@mail.gmail.com> <SJ0PR22MB25424D58B3069358F1984B3EE8CF9@SJ0PR22MB2542.namprd22.prod.outlook.com> <SA1PR03MB662685DCB0CDF5BCACBDCEBEEECF9@SA1PR03MB6626.namprd03.prod.outlook.com>
From: Eliot Lear <lear@lear.ch>
Message-ID: <f49eb436-f3ca-053b-9874-9057420f8cb6@lear.ch>
Date: Fri, 03 Sep 2021 14:56:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <SA1PR03MB662685DCB0CDF5BCACBDCEBEEECF9@SA1PR03MB6626.namprd03.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="AM0qyPimOjSfrAjwCbZos0hE4Wu35mcJl"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/h5Oy9Iqdt8wrmvBMnD4lgAZFwjY>
Subject: Re: [lamps] rollover of CA
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2021 12:56:54 -0000

I think the issue is that RFC 7030 references RFC 4210.  And enterprises 
may indeed roll their CAs for a myriad of reasons, not the least of 
which could be mergers, mishandled private keys, and planned changes,.  
So some advice may be needed here, if 4210 isn't the right answer.

Eliot

On 03.09.21 14:21, Brown, Wendy (10421) wrote:
>
> In the case of longer lived certificates (for example within Federal 
> PKI most subscriber certs are 3 year) having the old CA key signed by 
> the new key allows the certificates signed by the older key to be 
> trusted with a path through the newer key to a trust anchor without 
> having to maintain 2 distinct paths to that same trust anchor.
>
> e-e -> ICA old key -> ICA new key - > root
>
> vs
>
> e-e -> ICA old key -> root AND  e-e -> ICA new key -> root
>
> Key rollover is still fairly common within the US federal government.
>
> Wendy Brown
>
> Protiviti Government Services
>
> wendy.brown@protiviti.com
>
> *From:* Tomas Gustavsson <tomas.gustavsson@primekey.com>
> *Sent:* Friday, September 3, 2021 2:21 AM
> *To:* Deb Cooley <debcooley1@gmail.com>; Ryan Sleevi 
> <ryan-ietf@sleevi.com>
> *Cc:* SPASM <spasm@ietf.org>; Michael Richardson <mcr+ietf@sandelman.ca>
> *Subject:* Re: [lamps] rollover of CA
>
> I remember being part of that discussion Michael.
>
> RFC4210 describes it in section 4.2.
>
> https://datatracker.ietf.org/doc/html/rfc4210#section-4.4 
> <https://datatracker.ietf.org/doc/html/rfc4210#section-4.4>
>
> In reality I have only seen rollover using newWithOld, for example in 
> ICAO 9303 part 12 (there called Link Certificate). The purpose being 
> to be able to automatically update trust anchor with a new Root if you 
> already trust the old Root.
>
> https://www.icao.int/publications/Documents/9303_p12_cons_en.pdf 
> <https://www.icao.int/publications/Documents/9303_p12_cons_en.pdf>
>
> I have never understood the purpose  of, or seen a practical use, of 
> OldWithNew. Therefore the CMP Update draft puts the link certificates 
> as optional instead of mandatory.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates#section-2.15 
> <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates#section-2.15>
>
> The old notion of having them as mandatory puts unrealistic burden on 
> CA rollover imho.
>
> Cheers,
>
> Tomas
>
> ------------------------------------------------------------------------
>
> *From:*Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org>> 
> on behalf of Deb Cooley <debcooley1@gmail.com 
> <mailto:debcooley1@gmail.com>>
> *Sent:* Thursday, September 2, 2021 9:38 PM
> *To:* Ryan Sleevi <ryan-ietf@sleevi.com <mailto:ryan-ietf@sleevi.com>>
> *Cc:* SPASM <spasm@ietf.org <mailto:spasm@ietf.org>>; Michael 
> Richardson <mcr+ietf@sandelman.ca <mailto:mcr+ietf@sandelman.ca>>
> *Subject:* Re: [lamps] rollover of CA
>
> *CAUTION:*External Sender - Be cautious when clicking links or opening 
> attachments. Please email InfoSec@keyfactor.com 
> <mailto:InfoSec@keyfactor.com> with any questions.
>
> What exactly are you interested in?
>
> Today's CA systems do this in a variety of ways.
>
> We (US DOD) have Root CAs, and sub CAs.  We don't roll any of that 
> over.  We stand up new Roots and new subCAs.  In general, we don't 
> name them the same.  When a new Root or sub CA is stood up, we make an 
> announcement to the community and there is an app that makes it easier 
> to do the trust store management. US Fed PKI just stood up a new Root 
> CA for their Common Policy Root CA - same thing, different name, 
> different keys, different dates, and (I think) different key sizes.
>
> Some CA's will rekey.  Name remains the same, key changes, dates 
> change (At least the expiry date).  I'm not (personally) familiar with 
> how this is managed.   I want to say that Entrust's systems work that 
> way (I could easily be wrong tho).
>
> Ryan can tell you more about how the public trust stores manage a Root 
> CA update/rekey/whatever.
>
> Deb Cooley
>
> decoole@nsa.gov <mailto:decoole@nsa.gov>
>
> On Thu, Sep 2, 2021 at 11:09 AM Ryan Sleevi <ryan-ietf@sleevi.com 
> <mailto:ryan-ietf@sleevi.com>> wrote:
>
>     I mean, there's
>     https://datatracker.ietf.org/doc/html/rfc4210#section-4.4
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-4.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ol1o%2B3jtez%2BHp5nR48hT3drrlbQ83PRziNY23d4%2FUmI%3D&reserved=0>
>     , but that's more or less unsupported, and would strongly
>     recommend against it: the _key_ rollover creates vast issues with
>     implementations.
>
>     Otherwise, if we're talking about (Subject + SPKI) changes, that's
>     just normal cross-certification. RFC 4158 is not widely supported
>     in implementations (particularly open-source software), so care
>     must be taken.
>
>     Other protocols take different approaches (e.g. RFC 6489), tied in
>     to the overall protocol.
>
>     On Thu, Sep 2, 2021 at 10:10 AM Michael Richardson
>     <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>> wrote:
>
>
>         Hi, sometime in 2021, we had a thread discussing how to rollover a
>         certification authority, and the process of signing old CA
>         with new CA.
>         I know that I wrote emails about this, but I can't find them
>         either in the archives or in my outbox.
>
>         I also can't find the RFC which describes this... somewhere in
>         the 2000s?
>
>         --
>         Michael Richardson <mcr+IETF@sandelman.ca
>         <mailto:mcr%2BIETF@sandelman.ca>>  . o O ( IPv6 IøT consulting )
>                    Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>         _______________________________________________
>         Spasm mailing list
>         Spasm@ietf.org <mailto:Spasm@ietf.org>
>         https://www.ietf.org/mailman/listinfo/spasm
>         <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2BFJW5VpaD2K%2FWLw9cHTWcj3e02Q1z2Ob%2FB%2FS1uNb6k%3D&reserved=0>
>
>     _______________________________________________
>     Spasm mailing list
>     Spasm@ietf.org <mailto:Spasm@ietf.org>
>     https://www.ietf.org/mailman/listinfo/spasm
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2BFJW5VpaD2K%2FWLw9cHTWcj3e02Q1z2Ob%2FB%2FS1uNb6k%3D&reserved=0>
>
> NOTICE: Protiviti is a global consulting and internal audit firm 
> composed of experts specializing in risk and advisory services. 
> Protiviti is not licensed or registered as a public accounting firm 
> and does not issue opinions on financial statements or offer 
> attestation services. This electronic mail message is intended 
> exclusively for the individual or entity to which it is addressed. 
> This message, together with any attachment, may contain confidential 
> and privileged information. Any views, opinions or conclusions 
> expressed in this message are those of the individual sender and do 
> not necessarily reflect the views of Protiviti Inc. or its affiliates. 
> Any unauthorized review, use, printing, copying, retention, disclosure 
> or distribution is strictly prohibited. If you have received this 
> message in error, please immediately advise the sender by reply email 
> message to the sender and delete all copies of this message. Thank you.
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm