[lamps] PKIX NameConstraints and SAN logic

"Sipos, Brian J." <Brian.Sipos@jhuapl.edu> Thu, 01 August 2024 20:17 UTC

Return-Path: <Brian.Sipos@jhuapl.edu>
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 D3096C1519BA; Thu, 1 Aug 2024 13:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqMVrXxHMQVi; Thu, 1 Aug 2024 13:17:14 -0700 (PDT)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) by ietfa.amsl.com (Postfix) with ESMTP id 5A527C180B6C; Thu, 1 Aug 2024 13:17:14 -0700 (PDT)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.17.1.19/8.17.1.19) with ESMTP id 471EC3r8004952; Thu, 1 Aug 2024 16:17:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=content-type : date : from : message-id : mime-version : subject : to; s=JHUAPLDec2018; bh=BhQNGetQQ8kuL75z94f9YgvfFheC40dYjSCZsRwN5Ms=; b=Qs0Qrfqdk6CsdcpNRlHxsa99f8m4Rqxo8HsBYQaRPZrgEpqS8zKB4A8IvkGxD/s/5LZI lLYgcDmnMzSNW+hBMWsRO98kqyI5St82DtARzWq7Rbgmf4MEun/+uwkDhFKrkduxLiUD b0MaEjxjczakDsMMQu00IP/ucndsfXm6D1uREDBE1YFl8XA+M+97Msp37N0F/qo4KX7g pcGITv4BOrDG6NrG1e1TqWu0+IE6WRcbnFO2/N18e9q+WN14d3tSHtjt3QpX/lq/2Wb5 JckjpF3BpGrnk9Xnx1TgnsTy5MN/0Xy/lUHCTA3VJpppA0+Jm1BCBSeXcFyW1yBt3Grk iw==
Received: from aplex24.dom1.jhuapl.edu (aplex24.dom1.jhuapl.edu [10.114.162.9]) by aplegw01.jhuapl.edu (PPS) with ESMTPS id 40msxax0tb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Aug 2024 16:17:13 -0400
Received: from APLEX21.dom1.jhuapl.edu (10.114.162.6) by APLEX24.dom1.jhuapl.edu (10.114.162.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 1 Aug 2024 16:17:12 -0400
Received: from APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2]) by APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2%5]) with mapi id 15.02.1544.011; Thu, 1 Aug 2024 16:17:12 -0400
From: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
To: "spasm@ietf.org" <spasm@ietf.org>, "cose@ietf.org" <cose@ietf.org>
Thread-Topic: PKIX NameConstraints and SAN logic
Thread-Index: AdrkSl2mKVk8wNd3TjiqFbeaQlQz2w==
Date: Thu, 01 Aug 2024 20:17:12 +0000
Message-ID: <b363510664824be08966ee310f7e7514@jhuapl.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.162.18]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0000_01DAE42E.40E0BDF0"
MIME-Version: 1.0
X-CrossPremisesHeadersFilteredBySendConnector: APLEX24.dom1.jhuapl.edu
X-OrganizationHeadersPreserved: APLEX24.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-08-01_18,2024-08-01_01,2024-05-17_01
Message-ID-Hash: 3JFYASHSUEJR2ZHJYKHCT2S4GCN3EV3E
X-Message-ID-Hash: 3JFYASHSUEJR2ZHJYKHCT2S4GCN3EV3E
X-MailFrom: Brian.Sipos@jhuapl.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [lamps] PKIX NameConstraints and SAN logic
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/_JPy9ro7eYAZ5r_HqwgFAXadqaI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Owner: <mailto:spasm-owner@ietf.org>
List-Post: <mailto:spasm@ietf.org>
List-Subscribe: <mailto:spasm-join@ietf.org>
List-Unsubscribe: <mailto:spasm-leave@ietf.org>

All,

In reading through the logic of PKIX base profile related to Name
Constraints [1], it appears that the relationship between the GeneralName of
the constraint subtrees and the GeneralName of the SAN being constrained is
based on correlating the GeneralName tag and the OtherName type-id between
the two. But I don't see any actual requirement that this is the case, just
an implication based on how the statements in [1] are phrased and the
scoping statement:

 

   The syntax and semantics for name constraints for otherName,

   ediPartyName, and registeredID are not defined by this specification,

   however, syntax and semantics for name constraints for other name

   forms may be specified in other documents.

 

So is the correlation of OtherName type-id necessarily the case, or is it
more flexible?

Meaning, could I define an Other Name Form so that NameConstraints has
OtherName type-id _OID1_ that actually constrains a SAN with OtherName
type-id _OID2_? Or is that kind of cross-constraining just going to run into
implementation hurdles and not worth trying?

 

The reason I bring this up is that there is similar logic for c509
certificates [2] using COSE encoding but not a strong model of how the "C509
General Names Registry" are supposed to relate beween GeneralName used in
SAN or similar and when used in Name Constraints. The Name Constraints
values typically involve patterns, either glob/wildcard or in the case of
ipAddress a CIDR block rather than a single address. There is a proposal for
a bundle EID Pattern [3] that seems like it would have utility within a Name
Constraints but can that constraint apply to a single EID value
(id-on-bundleEID; 1.3.6.1.5.5.7.8.11), but that would mean a Name
Constraints with one type-id OID limiting the contents of a SAN value with a
different type-id OID.

 

If the OtherName type-id must be equal then the draft [2] might need to be
more clear about some of its General Names Registry uses (i.e. do they apply
or not apply to Name Constraints).

Thanks for any feedback from those with more visibility into PKIX
systems/tools.

Brian S.

 

[1] https://www.rfc-editor.org/rfc/rfc5280.html#section-4.2.1.10

[2]
https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-11.html

[3] https://www.ietf.org/archive/id/draft-sipos-dtn-eid-pattern-02.html