> On Jun 28, 2020, at 1:01 PM, Toerless Eckert <t...@cs.fau.de> 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 nore...@example.com 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 nore...@example.com.
>
> 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:
>
> nore...@example.com 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 nore...@example.com 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 nore...@example.com 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
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
