Re: [Anima] representing ACP info in X.509 certs

Eliot Lear <> Wed, 24 June 2020 07:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B44E3A0C1F for <>; Wed, 24 Jun 2020 00:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GtpGVwrk0SuY for <>; Wed, 24 Jun 2020 00:05:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 063F73A0CE5 for <>; Wed, 24 Jun 2020 00:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9416; q=dns/txt; s=iport; t=1592982306; x=1594191906; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=59iBREKEQHRLxX1+R8mfCLNUDzwBziuyOMCub4hHD7o=; b=NcD2cpejb9zGPAxnPJvJjpMUhM0Zu8zhhatsK6M/Kk7vEThSHkLq3OYT x3idqSEbqt/Sctj9Sft6XidkhyfdA5CJbV1F0kWPpvR1lRFpA6aF63xwR g4yeFDGfOR/UquSb9QURLEVtZM+J90uf8nSxWj+JxDpJx0jRRZsHNUxOK U=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.75,274,1589241600"; d="asc'?scan'208,217";a="24959434"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2020 07:05:01 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 05O750VR029763 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 07:05:01 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_12948B6D-8173-4928-94E2-7073EB0FC089"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 24 Jun 2020 09:04:59 +0200
In-Reply-To: <15951.1592960140@localhost>
Cc: Anima WG <>, Eric Rescorla <>, Stephen Kent <>
To: Michael Richardson <>
References: <> <> <> <> <> <> <> <15951.1592960140@localhost>
X-Mailer: Apple Mail (2.3608.
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [Anima] representing ACP info in X.509 certs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jun 2020 07:05:27 -0000

Hi there,

> On 24 Jun 2020, at 02:55, Michael Richardson <> wrote:
> Signed PGP part
> Stephen Kent <> wrote:
>> The simple answer is that when, in the past, developers have chosen to abuse
>> the semantics of subject name fields in certs, the result shave been VERY
>> long lasting, and embarrassing. Long ago, Netscape chose to shove a DNS name
>> into the DN common name filed because it was an easy fix for their
>> problem. As a result, we still have browsers and CAs that misuse that
>> field. At least that egregious behavior was not the result of an IETF
>> WG. Let's not screw this up in the name of expediency!
> Yes, I remember that.
> Why do you think Netscape did that?
> What should they have done instead?

Going further, sometimes expedients are appropriate.

With the benefit of hindsight of nearly 30 years of experience, there’s a lot that Netscape did in its first years that we wouldn’t do today, but had they not done those things, field delivery could have been delayed by years, probably the worst example being the User-Agent header.  We can say, “they never should have done that”, but it was what people deemed necessary and expedient for a number of reasons, not least of which was product differentiation and market maturity.

Here we have a situation where the public CA offerings have been made quite brittle. The ability to add either an otherName or a URI requires CAs to modify their code and create alternative roots.    We all know that won’t happen, and so that leads to whether an expedient is appropriate.  Worse, as I have demonstrated, submitting otherName to public CAs produces garbage in certs (very bad, but there it is).  They not only aren’t ready, but they may have potential exploits lingering.

Is an expedient appropriate?

With ACP it’s clear they are overloading semantics of an rfc822name, and from an application standpoint we don’t like that because it is possible that different subsystems may have different uncoordinated allocation methods.  That is- someone may be able to nab an email address via the mail subsystem a la <>, get a cert for that address, and masquerade as an AN or an AN could start sending email as a user that has such an address.  Let’s agree that the latter is so minimal a risk as to not warrant further discussion.  It’s only the former that’s really of concern.  That can be mitigated through operational guidance, a’la “don’t allow email addresses in your domain that begin with rfcSELF+”.

It’s not perfect.  That’s the nature of an expedient.  But it’s probably Good Enough for now.  For the eventuality that another name could be used over time, it’s probably worth getting an OID and using otherName where possible, but we shouldn’t hold this work up over a highly theoretical attack.