Re: [Anima] No certs for noreply (was: Re: Russ: Re: rfc822Name use in Autonomic Control Plane) document

Russ Housley <> Mon, 29 June 2020 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD45A3A0F0B for <>; Mon, 29 Jun 2020 06:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a_7dTVRfiFEx for <>; Mon, 29 Jun 2020 06:59:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41EA33A0F0A for <>; Mon, 29 Jun 2020 06:59:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C834E300B12 for <>; Mon, 29 Jun 2020 09:59:10 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id jOuX3EqL7IPY for <>; Mon, 29 Jun 2020 09:59:07 -0400 (EDT)
Received: from a860b60074bd.fios-router.home ( []) by (Postfix) with ESMTPSA id B8134300AE4; Mon, 29 Jun 2020 09:59:07 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Russ Housley <>
In-Reply-To: <>
Date: Mon, 29 Jun 2020 09:59:09 -0400
Cc: Brian Carpenter <>, Michael Richardson <>, Ben Kaduk <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <9406.1592756905@localhost> <> <> <> <> <> <> <> <>
To: Toerless Eckert <>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <>
Subject: Re: [Anima] No certs for noreply (was: Re: Russ: Re: rfc822Name use in Autonomic Control Plane) document
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: Mon, 29 Jun 2020 13:59:15 -0000

> On Jun 28, 2020, at 1:01 PM, Toerless Eckert <> wrote:
> On Sun, Jun 28, 2020 at 10:36:34AM -0400, Russ Housley wrote:
>>> You also did not repy to my expamples about other systems where
>>> email addresses are primarily used for non-mailbox purposes
>>> but still encoded in rfc822Name. I have seen no outlawing of
>>> this practice through IETF documents.
>> It is clear that has the syntax of an email address, but there is not corresponding mailbox.  For that reason, it should not appear in a certificate.  It is the the email address of the subject of the certificate.
> Ok, i think this simple example allows me maybe to understand the process better.
> So, if i was to write a target normative RFC explaining for example 
> certificates for "customer communications" departments of that would
> result in creation of certs with rfc822Name
> This draft passes 5 years through WG and all IETF/IESG review except SEC review.
> What now are the criteria by which your opinion should be vetted as a blocker
> for IESG approval of the document ?
> I for once received numerous email in private that it is impossible to argue
> opinions of security people in IETF technically, just because of the weight that their
> names carry with IESG, so i shouldn't even try technical arguments. And i fear this is
> true, and some of the other emails here (not from you) also indicate this to me.
> If not, then i would like to hear what you think the process should be.
> If this is  the process, then i should obviously stop making technical
> arguments, accept defeat and move on. Hopefully we will at least be allowed
> to document in the RFC how easier implementable and deployable solutions
> where unacceptable due to ... understanding of the required semantic of
> rfc822Name content. Otherwise we would loose the whole discussion here.
> I already feel that the process is injust because i seem to
> have to prove that what we are doing is not in violation of RFC/semantics,
> which to me sounds like i have to prove our draft is "innocent", whereas
> i was under the assumption that the burden of proof was opposite.
> Wrt to the technical argument:
> is an interesting example, because i hate receiving these
> emails, so i would LOVE to see a normative RFC saying that these type of
> email addresses MUST NOT get certificates. However, technically i think that
> is not defensible, because obviously (to me) its perfect valid for a
> mailbox to not receive or not to send emails. Its to me just a controlled subject
> with a name/address.
> And customer harrasment departments are of course also
> interested to be protected from phishing and the like, so they will
> of course also use certificates for mails from as soon
> as enough customers would understand security (*sigh*). And i am willing
> to take any bet with you, that there will be nothing from the IETF that
> normatively says this should not be done. 

No.  I go not agree.  The mailbox is not ever used to communicate with the party that holds the private key.  So, it should not be bound to the subject public key in a certificate.