Re: [lamps] Last Call: <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC

Russ Housley <housley@vigilsec.com> Wed, 09 January 2019 16:51 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6058E130F0D for <ietf@ietfa.amsl.com>; Wed, 9 Jan 2019 08:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 SPi2U9X2KVqV for <ietf@ietfa.amsl.com>; Wed, 9 Jan 2019 08:51:38 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FA7130F14 for <ietf@ietf.org>; Wed, 9 Jan 2019 08:51:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 756EB3004FE for <ietf@ietf.org>; Wed, 9 Jan 2019 11:33:20 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IcXIH_mh3Eur for <ietf@ietf.org>; Wed, 9 Jan 2019 11:33:17 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id CB667300080; Wed, 9 Jan 2019 11:33:16 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: [lamps] Last Call: <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <87k1jlnxnu.fsf@fifthhorseman.net>
Date: Wed, 09 Jan 2019 11:51:33 -0500
Cc: LAMPS WG <spasm@ietf.org>, draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com>
References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/a5ttHiI8f7AVU4MbAGbuyERQhoQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2019 16:51:46 -0000

DKG:

>> I could add a sentence here:
>> 
>> 	If both checks succeed, then the potential Root CA certificate is
>> 	added to the trust anchor store and the current  Root CA
>> 	certificate is removed.
>> 
>> Does that resolve your concern?
> 
> Yes, this final addition clarifies the intent of the document, thank
> you.  I might prefer if it was active voice instead of passive, just to
> be clearer about who is doing the addition and removal to the trust
> store.  Is there a reason to avoid RFC 2119 language in these
> descriptions?

Yes, active voice would be better:

   If both checks succeed, then the recipient adds the potential
   Root CA certificate to the trust anchor store and removes the
   current Root CA certificate.

I do not see the need for RFC 2119 language in the Overview section.

>> Please take a look at RFC 4210, Section 4.4 ("Root CA Key Update").
> 
> Please cite the relevant section number directly in the draft!

I have added it in my edit buffer.

>> The way that I read the section, it is describing a technique for
>> protecting the new public key using the previous private key and vice
>> versa.  The technique involves both old-with-new and new-with-old.
>> 
>> To be more clear, I will refer to "this advice" in all of the places
>> that reference RFC 4210.  The current text uses "this advice" in one
>> place and "this technique" in another place.  I hope that will be more
>> clear.
> 
> So i think you're now saying that people updating a key should use RFC
> 4210§4.4 guidance *in addition* to including the HashOfRootKey extension
> in C1.  If that's what you mean, the draft should say it explicitly.

Yes, this advice has been in place since 1999 for root key transition.

This is what I have in my edit buffer:

   Guidance on the transition from one trust anchor to another is
   available in Section 4.4 of [RFC4210].  In particular, the oldWithNew
   and newWithOld advice ensures that relying parties are able to
   validate certificates issued under the current Root CA certificate
   and the next generation Root CA certificate throughout the
   transition.  Further, this advice SHOULD be followed by Root CAs to
   avoid the need for all relying parties to make the transition at the
   same time.

> But (using the RFC 4210 terms), let's think about what happens to the
> PSE (Personal Security Environment), the trust store (meaning the list
> of trusted roots, which is a subset of the PSE, i guess, feel free to
> correct if i'm misunderstanding 4210) and various certificates assuming
> there are multiple heterogeneous subscribers seen by a single relying
> party.
> 
> I'm working here on a TLS assumption -- if you're using these certs for
> some other purpose (like LAMPS) maybe it won't apply, i'm not sure.  The
> "Repository" referred to in RFC 4210 isn't something that many X.509
> verification stacks have access to (and even if it was, checking it
> during failed verification might raise privacy or latency concerns).
> 
> In my notation below, the CA starts with self-signed C1, and then moves
> (via HashOfRootKey) to self-signed C2.  Meanwhile, the CA has also
> generated COwN (the oldWithNew cert) and CNwO (the newWithOld cert).
> (C1 is oldWithOld, and C2 is newWithNew, in 4210 lingo).
> 
> In my example, an end-entity cert might be written as EA or EB, and will
> be signed by the root authority directly (i'm omitting traditional
> intermediate certs for the sake of simplicity, though i note that COwN
> and CNwO are effectively intermediate certs).
> 
> A valid simple certificate chain where end entity A is certified by the
> first version of the CA looks like this: EA←C1.  Let's assume that all
> servers ship their root CA certs as well (though TLS doesn't explicitly
> require that, and people who care about latency are likely to try to
> omit them -- should this draft explicitly recommend that TLS servers
> ship root certs all the time just in case?).
> 
> in this example scenario, the relying party visits site end entity A
> (which whose cert has been issued by the new C2), and then end entity B
> (which is still using a cert issued by C1).
> 
>        | Trust |       | cert  |
> event  | Store | PSE   | chain | valid?   
> --------+-------+-------+-------+----------
> start   | C1    | C1    |       |
> visit A | C2    | C1,C2 | EA←C2 | EA = ✓
> visit B | C2    | C1,C2 | EB←C1 | EB = ?
> 
> 
> It looks to me like EB will not validate, since:
> 
> 1) C1 is no longer a trusted root, despite being in the PSE
> 
> 2) COwN is not available to the relying party (and might not be known
>    to server B either), so no chain can be formed to the only trusted
>    root, C2
> 
> What am i missing?  This looks like a recipe for one party (A) to
> accidentally damage another party (B) due to lack of coordination.
> 
> Furthermore, what happens if the relying party comes across CNwO before
> C2?  It validates (signed by C1) but it is not self-signed.  But its
> SPKI also matches C1's HashOfRootKey extension.  If it gets processed as
> a new root, then C2 will *not* get processed (because C1 is already out
> of the trust store, and C2 doesn't have the same HashOfRootKey as C1).
> So now you'll have some RPs that have CNwO in their root store, and
> others that have C2, depending on when they encountered it.  Hopefully
> that won't cause any problems, but it makes me nervous.
> 
> Alternately, maybe this process *only* triggers when the cert we're
> examining is self-signed.  Maybe the text "Whenever a new Root CA
> certificate is received" is meant to only apply to self-signed
> certificates?  perhaps it should be clearer on that, if that's the case
> (subsequent text in that paragraph refers to "the self-signed
> certificate", but the only "self-signed" antecedent in that paragraph is
> the original "Root CA self-signed certificate" -- C1, not a potential
> C2).

I think about this quite differently.  Let me see if a few high-level comments can resolve this question in the TLS context.

First, TLS explicitly says that intermediate certificates can be included in the "certificate_list" during a transition.  RFC 8446 says:

   Note: Prior to TLS 1.3, "certificate_list" ordering required each
   certificate to certify the one immediately preceding it; however,
   some implementations allowed some flexibility.  Servers sometimes
   send both a current and deprecated intermediate for transitional
   purposes, and others are simply configured incorrectly, but these
   cases can nonetheless be validated properly.  For maximum
   compatibility, all implementations SHOULD be prepared to handle
   potentially extraneous certificates and arbitrary orderings from any
   TLS version, with the exception of the end-entity certificate which
   MUST be first.

So, a server can provide the intermediate certificates needed for a client that is using the old self-signed certificate and the new self-signed certificate so that both validate the servers end-entity certificate.

I observe that other protocols, including CMS, allow a bag of certificates that might be useful to be sent.  During a transition, this could help populate caches.

Second, it is quite clear that a global directory has not emerged in the way envisioned by X.500 and LDAP.  However, there are many repositories within enterprises, and these repositories can be used to locate the old-in-new and new-in-old certificates during a transition.  This is the situation for the PKI that I know about that will be using this extension.

>> The whole point of the old-with-new and new-with-old advice is that
>> all of the certificates can be validated to either the old trust
>> anchor or the new one.
> 
> only if the relying party has access both COwN cert as well as C2,
> right?  If the TLS server ships only C1, then the RP is out of luck.
> 
> should COwN have the same subjectPublicKeyIdentifier extension as C1?
> should CNwO have the same subjectPublicKeyIdentifier as C2?  if so,
> should we say so explicitly?

I think my comments above address this point as well.

>>> So, without this draft offering a strong and immediate revocation
>>> mechanism, and without it cleaning up the pre-existing new-root-cert
>>> import mechanism, it does *not* make "rollover more secure" (since all
>>> existing insecure channels will continue to exist).  It just makes good
>>> rollover more convenient/automatic.
>> 
>> Yes, that is the point of the extension.
> 
> thanks, that matches my mental model.

Okay.  Good.

> One other open question occurs to me: Should the relying party also
> verify that Subject information (or other identity info) in the new cert
> matches the old certificate?  I'm imagining a case where the old root CA
> ("O=L'Emporium de Foobar,OU=Authorité Racine,C=FR") ends up replacing
> itself with ("O=Вооружённые Силы Союза Советских Социалистических
> Республик,C=SU").  That would be pretty weird and upsetting, especially
> if i didn't know how my "new" Soviet military cert got into my trust
> store.  Would it be legitimate to cabin the scope of this rollover to
> identical Subjects?

I do not think so.  We have seen cases in the Web PKI were the Root CA changed names as part of a key rollover.  Of course, this happens without this extension today, so they establish a new self-signed certificate and once it is well established, they issue new certificate under the new root and stop issuing certificates under the old one.

> Finally, should a relying party place any bounds on the lifetime of the
> new cert?  What if C2 appears, but has an *earlier* notBefore date than
> C1?  that seems weird but maybe it isn't a problem.  But what if i've
> added a cert to my root store with an known expiration date, and i don't
> *want* a subsequent cert to suddenly have a later expiration date? (for
> example, perhaps i'm in school and the school issues its own annual
> certificate authority which i'm fine with accepting for now, but i don't
> want to trust it after graduation)

I cannot think of a reason for the new self-signed certificate to have a notBefore date that is earlier than the old one.  That said, the certification path validation rules in RFC 5280 do not use the validity period in the trust anchor.  As a result, I cannot see any attack that would be enabled by this admittedly weird use of notBefore.

> How can an implementation determine the intent of the local system's
> inclusion of certificate in the root store?  Should we encourage trust
> store implementations to be able mark certificates as DO NOT UPDATE?  or
> should we instead encourage users to understand inclusion of a
> certificate in a root store as effectively unbounded in duration,
> despite the existence of a validUntil field?

I am missing something in this paragraph.  If the relying party has already decided to trust a particular Root CA, and then that Root CA transitions to a different key pair, what does this have to do with that decision?  If trust in the Root CA is lost by the relying party, then they ought to remove the self-signed certificate from the trust anchor store.

Further, I do want this extension to say anything about the structure of the trust anchor store.  Rather, it depends on the definition of a trust anchor in RFC 5280 (on page 76), which says:

      (d)  trust anchor information, describing a CA that serves as a
           trust anchor for the certification path.  The trust anchor
           information includes:

         (1)  the trusted issuer name,

         (2)  the trusted public key algorithm,

         (3)  the trusted public key, and

         (4)  optionally, the trusted public key parameters associated
              with the public key.

Finally, I want to thank you for all the careful thought that you have put into this discussion.

Russ