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. Cheers Toerless > > Russ _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima