IETF Logo Mail Archive

Re: [saag] [lamps] subordinate vs intermediate certification authority

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 08 February 2021 17:13 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCA53A138C; Mon, 8 Feb 2021 09:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 vP_TBmL4xRml; Mon, 8 Feb 2021 09:13:47 -0800 (PST)
Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (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 798A33A10F6; Mon, 8 Feb 2021 09:13:47 -0800 (PST)
Received: by mail-yb1-f179.google.com with SMTP id p193so1575496yba.4; Mon, 08 Feb 2021 09:13:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s4WblOnNPSthSXULpKE2D7aCKxRsiy3G6JBo0TZRx1k=; b=EIBiqfjo9Cl98V8fG0WnH53AJ7xyaLn+lIAVLZc0J9pqBrwNvsUh0G7xNYyDTZab2C +ZyAO16FET9X9W0TfWSwHl+O0WChwp0SPTWf9GTrqfAZckiDX4oAeO6KBnP6zHzmewGP o9DGqTrOgdX53eCXVv1dG34IwIuD82meil81spOPEAXoQ3NhyV3gI8EVtFFpeLOc+5l/ wdJVQ2Ud4coc58gxm1MgZDqnrT2aNu7JgflY9BokvNk6UDCN5TBI/pWh1aOB8t75XZUh KEooJx0Nkvcy20LMICuQ2mXugqNmlhra3Dutci5zkEWqbjZDnXqeJJj0n1tTe5UR8yq2 gJhg==
X-Gm-Message-State: AOAM5300vRnLlB1J73fL+I9B+SApIWihsdLxyweTyQYyBOgOnQAU47IG Z/4QLuL5IrmJkiHxWDf05Sn2xKim9qCUnW9NChE=
X-Google-Smtp-Source: ABdhPJzS4SVBI3RASd9+KvzXGhIk0chpwKLfQsy5BFt6Nm4qxwzwT8ujPeKFZdp8OtKbnr6GwxROsl2Puo5jrL5kLmU=
X-Received: by 2002:a25:c5c1:: with SMTP id v184mr26934187ybe.56.1612804426627; Mon, 08 Feb 2021 09:13:46 -0800 (PST)
MIME-Version: 1.0
References: <30833.1612411843@localhost> <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> <6108.1612645177@localhost> <CAErg=HHesEG1T+39WCgFGa---wzd884FQNGLndT35dvVAKf+kA@mail.gmail.com>
In-Reply-To: <CAErg=HHesEG1T+39WCgFGa---wzd884FQNGLndT35dvVAKf+kA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 8 Feb 2021 12:13:36 -0500
Message-ID: <CAMm+Lwjks9M+yV0SOsne85eiycyNPm2NtHreDY3=BitAsqt18Q@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, LAMPS <spasm@ietf.org>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f0fd1805bad64a64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/RoTNWRFKK4oWQWEtatkFeHOV8OU>
Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2021 17:13:49 -0000

On Mon, Feb 8, 2021 at 11:49 AM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

>
>
> On Sat, Feb 6, 2021 at 4:00 PM Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
>
>>
>> Dr. Pala <madwolf@openca.org> wrote:
>>     > Developers and Practitioners (see the note on OpenSSL's conventions)
>>     > seem to support more the "Intermediate CA" for technical
>> conversations
>>     > while "Subordinate CA" is usually referred to in the context of PKI
>>     > policies.
>>
>> I think that this is the key point which you are supporting.
>>
>>     > RFC3647 talks about subordinate organizations instead - maybe that
>> is
>>     > the concept you need to use? What is weird about the question is the
>>     > different logical levels that you are trying to put together:
>> business
>>     > relationships and certification chains.
>>
>> The issue comes up with pinning as it relates to ownership.
>> It's not a problem if every organization that can own Things has it's own
>> private CA.  Pinning that CA works great.
>> Pinning some other EE is very much more specific, but also, may be too
>> ephemeral.
>>
>> Where it gets complex is when organizations have outsourced the CA
>> function elsewhere.
>> It's meaningless to pin LetsEncrypt or GoDaddy.  It might be meaningful to
>> pin a Subordinate CA signed by some public CA though.
>>
>
> No one, anywhere, should ever pin to a CA that they don’t directly
> control, and even then, they still shouldn’t :)
>

Almost agree. Should not pin to a PKIX CA.



> Pinning is just a poor-man’s attempt at a server controlling the client’s
> trust anchors, and thus inevitably runs into issues, since client policy is
> inherently _client_ policy. Especially important is never pinning to a
> so-called “public” CA, precisely because their very existence is predicated
> on client policy that is intentionally not controlled/controllable by
> servers.
>

I agree.


Pinning is a great idea in principle and PKIX pinning turns out to be a
lousy idea in practice. The fundamental problem is that every PKIX cert is
written from the assumption it will expire. And that is why trust anchors
in PKIX aren't actually PKIX certificates. This is true even when PKIX
syntax is used for distribution.

v2.8.7 | Report a Bug | By Email