Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document

[Toerless Eckert <[e-mail]>]

[Adding Barry and a few more folks]

Ben, Russ:

RFC5280 does not redefine anything about email addresses. It solely
refer to RFC2821 definitions of them. Russ' last email on this
thread explicitly reconfirmed that his concern is purely about
use of email addresses in anima wrt. his reading of RFC2821. 
I think he is inventing new legislation what is and what is
not a valid email address.

>From that perspective i ask you to consult with Barry which the
appropriate IETF WG is that has the expertise to provide input into
how to interpret RFC2821, the RFCs that obsoleted it, or in
general what does and what does not constitute a semantically
correct email address. Maybe emailcore WG. I don't know. Barry ?

There is ample explanation how what ACP uses as an email addrss
is in our opinion perfectly valid syntactically and semantically,
most of the argumens are in the numbered list in section 6.1.2
of the ACP draft. I have not seen any substantial technical
argument invalidating what is written there.

I have repeated written that ACP email addresses CAN HAVE
an actual mailbox associated with them when desirable, but
that like other common use-cases of email addresses such as
wifi roaiming authentication, where also rfc822Name are used to
certify ownership of such addresses, the main purpose of the use
of these addresses is not that of sending or receiving email.
I have pointed to examples like [e-mail] which also
is a typical example of a valid email address that arguably could
be interpreted to have no mailbox associated with it.

The ACP draft also well specifies how even in he absence of
a configured physical mailbox, the email address itself is
assigned such that it is under the control of the entity (ACP)
it identifies. Such that no one else but his entity could own
a mailbox for that email address.

If LAMPS is interested to define additional constraints on
email addresses required to make them legal to be put into PKIX
rfc822Name attributes, i think thatss thats group perogative,
but please:

Such future additional constrain work can not be used to hold
up progressing ACP now, especially not when it is just
personal prefernces for encoding without any technical
eplanation as to the harm the choice could provide.

Aka: If there i anything reasonable to ask LAMPS now, then it is
not to legislate what is a valid email address, but at most
to come up with possible harm of putting particular email
addresses into rfc822Name.

Cheers
    Toerless

On Sat, Jun 27, 2020 at 04:13:52PM -0700, Benjamin Kaduk wrote:
> My apologies for commenting before having caught up on the whole thread
> (I've been pretty sluggish all week and don't want to get even further
> behind.)
> 
> On Sat, Jun 27, 2020 at 03:58:21PM -0700, Eric Rescorla wrote:
> > 
> > Taking a step back from the substantive issue, it seems to me that to the
> > extent to which their is debate about the meaning of 5280, this is a
> > discussion which cannot be resolved entirely on this list, but instead
> > needs to involve the LAMPS WG.
> 
> This has been a key point that I've (apparently) been failing to make very
> well so far.  E.g., while the ANIMA WG has presumably reached consensus on
> the use of rfc822Name years ago, I think we also need consensus from LAMPS
> before we can be confident that there is IETF consensus.
> 
> Also, making even another step back, it seems that there is a key issue of
> the CA model in play here, namely "know what you sign".  If we are asking a
> CA to sign an rfc822Name, which the CA treats as having email semantics,
> but we assign different semantics to that name, then the CA is not actually
> in knowledge of what it's signing.  Accordingly, the CA incurs significant
> (e.g., legal and financial) risk by making those signatures, and defining
> the field in this way gives the impression that we are trying to make an
> end-run around CA policies.
> 
> -Ben

-- 
---
[e-mail]