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

[Russ Housley <[e-mail]>]

> On Jun 28, 2020, at 1:01 PM, Toerless Eckert <[e-mail]> 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 [e-mail] 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 example.com that would
> result in creation of certs with rfc822Name [e-mail].
> 
> 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:
> 
> [e-mail] 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 [e-mail] 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 [e-mail] 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.

Russ