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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 06 February 2021 20:42 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 6C65F3A2BCC; Sat, 6 Feb 2021 12:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 45M3JHsyZ0iE; Sat, 6 Feb 2021 12:42:13 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4543A2BCA; Sat, 6 Feb 2021 12:42:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BCC9389A9; Sat, 6 Feb 2021 15:45:16 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eiBt7iXOtsDl; Sat, 6 Feb 2021 15:45:15 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 40DC0389A7; Sat, 6 Feb 2021 15:45:15 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 28F69585; Sat, 6 Feb 2021 15:42:11 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "spasm@ietf.org" <spasm@ietf.org>, "saag@ietf.org" <saag@ietf.org>
cc: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
In-Reply-To: <AM0PR10MB2418085DF1EB0952EB6DFCEDFEB39@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM>
References: <30833.1612411843@localhost> <AM0PR10MB2418085DF1EB0952EB6DFCEDFEB39@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 06 Feb 2021 15:42:11 -0500
Message-ID: <986.1612644131@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/V7cmoQ1YlfAgVZjMGMGqpNVTQ-w>
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: Sat, 06 Feb 2021 20:42:15 -0000

Thanks for the many emails on this; I think that it was useful to me.

Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> wrote:
    > I also recognized the lack of clear definitions of these terms.

    > May be the definitions in the NIST glossary help.

Thanks, that's a good place to go.
I think that the NIST definitions are probably good enough for now.
(I wish revising RFC4949 was cheaper)

    > From NIST SP 800-32"
    > https://csrc.nist.gov/glossary/term/subordinate_CA "subordinate CA In a
    > hierarchical PKI, a CA whose certificate signature key is certified by
    > another CA, and whose activities are constrained by that other CA. (See
    > superior CA). From NIST SP 800-32"

    > The definition of intermediate CA from the NIST glossary differs to the
    > one in RFC 4949, but I think it fits better for todays use. The
    > definition of subordinate CA seems to fit well also with RFC 4949.

...

my conclusion is that mostly, the terms are interchangeable, but that
"subordinate" might be used when there is a clearer "constrained".
For instance, if there were a Path Constraint by the superior CA.

Or: all subordinate CAs are intermediate CAs, but not vv.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide