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

Reply via email to