Re: [saag] post-X509 cryptographic identities

Nico Williams <nico@cryptonector.com> Tue, 11 February 2020 19:21 UTC

Return-Path: <nico@cryptonector.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 6D3E7120A42 for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 11:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 F3FaN55GyFNa for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 11:21:42 -0800 (PST)
Received: from camel.birch.relay.mailchannels.net (camel.birch.relay.mailchannels.net [23.83.209.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E58120A4D for <saag@ietf.org>; Tue, 11 Feb 2020 11:21:42 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E350C501F27; Tue, 11 Feb 2020 19:21:40 +0000 (UTC)
Received: from pdx1-sub0-mail-a21.g.dreamhost.com (100-96-215-16.trex.outbound.svc.cluster.local [100.96.215.16]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 68B88502766; Tue, 11 Feb 2020 19:21:40 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a21.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 11 Feb 2020 19:21:40 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Eight-Well-Made: 0a53fbc0487adbc9_1581448900722_3017938545
X-MC-Loop-Signature: 1581448900722:1997909753
X-MC-Ingress-Time: 1581448900722
Received: from pdx1-sub0-mail-a21.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a21.g.dreamhost.com (Postfix) with ESMTP id 866D28033C; Tue, 11 Feb 2020 11:21:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=ZHXrxIehe6mh85+AOz6LfGEZG+A=; b=y6frGLtuNVs WFnivMcF9GcRuogbchmneGfVkKhewuvBEYzq22CDlkFn9RIub6XDTLKK3BGwwCwS 8SfuiO0SUEltmrYspdJKz0i7R8PWIbitSbnUJxzUQ/BNkuFv04733LzwDWCFdoko 0mx6fghIAO8ic+bqyvTqeIyFiHT4qbSY=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 831E880314; Tue, 11 Feb 2020 11:21:31 -0800 (PST)
Date: Tue, 11 Feb 2020 13:21:29 -0600
X-DH-BACKEND: pdx1-sub0-mail-a21
From: Nico Williams <nico@cryptonector.com>
To: trutkowski@netmagic.com
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, saag@ietf.org
Message-ID: <20200211192128.GN18021@localhost>
References: <CABcZeBOzJ2MRS8deZqN+e-o9tFDwgSrYK3_hmV-0pfO+L9oaVw@mail.gmail.com> <53c87d6b-cad1-3a80-291d-e2a896705da5@ericsson.com> <CABcZeBNJWmFTV==6sa0qnAPyRr4=6OiCacchzobE=RozHnqPdg@mail.gmail.com> <7901248e-c7dd-8a12-65df-f40415fde5e2@cs.tcd.ie> <26497.1581418516@dooku> <20200211165720.GH18021@localhost> <98b92ba2-f7a0-fd53-05f4-3d46dc27996f@netmagic.com> <20200211171927.GJ18021@localhost> <20200211173349.GK18021@localhost> <efdd8623-7a69-1c24-84e3-8cea3eb95742@netmagic.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <efdd8623-7a69-1c24-84e3-8cea3eb95742@netmagic.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrieefgdduudejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderudenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepohhiugdqihhnfhhordgtohhmnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/0LLmVtqg6sOazouIPPuysBACKQw>
Subject: Re: [saag] post-X509 cryptographic identities
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: Tue, 11 Feb 2020 19:21:46 -0000

On Tue, Feb 11, 2020 at 01:55:10PM -0500, Tony Rutkowski wrote:
> The patent would be worthless.  DNS for OID arc resolution was originally
> proposed by VeriSign's Michael Mealling about 20 years ago in RFC3061,

Yes, I know it was long ago enough that it's probably expired.  It's a
minor relief to know it must be!

> introduced again by VeriSign in ITU-T about 15 years ago, and then pursued
> by Korea's ETRI as a series of ITU-T standards X.672, X.674, X.675 and
> X.676.  The root resolver authority is allocated to the Korean Information
> Security Agency. It is known as the OID Resolution System (ORS).  Orange's
> research centre has long maintained a http based resolver at the OID
> Repository site, www.oid-info.com.  Note the KISA Activity for the ORS on
> the OID-INFO site.

Interesting.  Thanks for the info.

> OIDs rank as one of the most ubiquitous object identifiers and in addition
> to ASN.1 code and X.509 PKI cert information, it has found favor in recent
> years for IOT tagging.  It is resolved to all kinds of information.

Yes.  But they are not useful for _humans_.

We even use OIDs in APIs, e.g., the GSS-API.  A mistake that.  URNs are
much simpler and easier to use for developers.

Just say not to OIDs.  Use URNs, and if you have an OID, remember that
there's a URN form for OIDs.

Yes, of course, on the wire in PKIX and many other protocols we have to
use OIDs where the relevant protocols use them.  But there's no need to
bleed these into APIs, let alone UIs.

Nico
--