IETF Logo Mail Archive

[lamps] discussing EST CSRATTRS specifying the SAN at IETF111

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 06 July 2021 13:59 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 8897C3A28EF; Tue, 6 Jul 2021 06:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 27ccheprPpEY; Tue, 6 Jul 2021 06:59:12 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9103A28ED; Tue, 6 Jul 2021 06:59:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3BA1638A41; Tue, 6 Jul 2021 10:01:39 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nGsjEZYBRkXi; Tue, 6 Jul 2021 10:01:36 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C4CA338A60; Tue, 6 Jul 2021 10:01:35 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A99072B3; Tue, 6 Jul 2021 09:59:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org, spasm@ietf.org
cc: David von Oheimb <nl0@von-Oheimb.de>, Eliot Lear <lear@lear.ch>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, Sean Turner <sean@sn3rd.com>
In-Reply-To: <529b66d9-1216-5e65-eb28-79a2de09d6a4@lear.ch>
References: <83844291-5785-434E-8956-3FF81ECD761C@cisco.com> <9820.1618358856@localhost> <MW3PR11MB47462121627A10A62E006497DB369@MW3PR11MB4746.namprd11.prod.outlook.com> <26435.1623269725@localhost> <25C432F7-EDEE-4FEA-B871-5D7F9311BBF7@sn3rd.com> <6e29b64d-0bc0-d129-beff-4072a482cfbd@von-Oheimb.de> <401152E2-9743-48FB-A3E1-3DE6873AE0A3@vigilsec.com> <31102501-F25D-4763-869B-3AD4165454BD@ll.mit.edu> <ff866861-551b-fdb2-792f-6d5d819f27bf@von-Oheimb.de> <529b66d9-1216-5e65-eb28-79a2de09d6a4@lear.ch>
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: Tue, 06 Jul 2021 09:59:07 -0400
Message-ID: <13163.1625579947@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/pJXb3N3UBSGKwiIxg9B8CCumUdc>
Subject: [lamps] discussing EST CSRATTRS specifying the SAN at IETF111
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: Tue, 06 Jul 2021 13:59:19 -0000

Hi, if David von Oheimb is correct that we've gotten use this
Type=SpecificValue for the CSRATTRS wrong, then this certainly affects
RFC8994, which requires that the pledge enroll with a specific otherName,
allocated by the Registrar.

I don't think that we ever got reliably to /san when interoperating Registrars in
2018's round of BRSKI testing. (Remember all those base64 issues...)
I expect to attempt this again between Registrar's again this month.
So, at least, we'll know if RFC8994/RFC8995 implementors got it consistent.
(Whether RIGHT or WRONG).

One answer is to just axe /csrattrs, and assume that the RA/CA will sort
things out.   Eliot has proposed to do away with the ASN.1 in /CSRATTRS, and
do JSON and/or CBOR here instead.  It certainly would be trivial to do,
and draft-ietf-cbor-tags-oid-08 could help here.

It's a bit of a toss-up of which bit of code you want to extend.

LAMPS chairs: can we have ten minutes for this discussion on the Thursday
      Session III meeting at IETF111?
      The Monday Session II is conflicted with ANIMA.

I'm gonna voluntold Eliot to lead this discussion :-)


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

v2.23.0 | Report a Bug | By Email