[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 [email protected] 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 -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
