Hi Eric, On 28-Jun-20 10:58, Eric Rescorla wrote: > I'm not Russ, but I don't take his point to be about ACME one way or the > other. > > Rather, I take his point to be (as he just said in his response to Brian) > that while this is *formatted* as an e-mail address, it does not in fact > correspond to something to which e-mail can be delivered
It might do, simply because it is so formatted. > and therefore does not match the semantics of RFC 5280. RFC5280 does not require such a mailbox to exist. Is there another normative document, e.g. a BCP, that does require one? It's entirely possible that the authors of RFC5280 assumed that such a mailbox would exist, but this is not written anywhere that I can see. So IMNSHO, this objection to the ACP draft is attempting to hold it to a standard that isn't documented. > 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. That may be true, but it's not ANIMA's fault and the discussion first arose last year, so why hasn't LAMPS already considered it, if it's important enough to continue obstructing ANIMA's progress? Brian > > -Ekr > > > > > On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <t...@cs.fau.de > <mailto:t...@cs..fau.de>> wrote: > > On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > > Toerless: > > > > I think Brian actually made my point. While the filed contains an > email address, using it as such would result in a delivery failure. The > private key holder cannot be reached by this address. > > Russ, i said: > > > First of all, you can if you want to, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Aka: Yes, if an ACP admin thinks ACME style challenge/reply > email authentication mechanism is useful, then he can of course > set up those email addresses accordingly. I did reply to that > point exhaustively in my reply about the ACME email mechanism. > > Why do you ignore that answer ? > > > and secondly, i contest that it is a requirement to be able > > to do that if the recipient doesn't need to support it. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Think about nore...@bad-corporation.com > <mailto:nore...@bad-corporation.com>. > > You do want to make sure though that you are in control of > > the electronic mail address though, and that is given for ACP > > addresses. > > Where in rfc5280 or any other generic RFC about certificates does > it say you MUST have a mailbox that is reachable ? Where does it > say that all certificiates with rfc822Name must be email boxes > that support ACME email style challenge-reply about the email address ? > I think this is a non-existing requirement against email addresses. > > Of course, nore...@bad-corporation.com > <mailto:nore...@bad-corporation.com> can have a certificate with > that rfc822Name. It just can't use the ACME mechanism to be > generated. But the signed mails sent from that address can be > authenticated. > > Or there are never emails, because the email address just serves > as identifier of an entity such as in wifi roaming identification > and authentication. In that case you are not authenticating > e.g.: password ownership for the email address via actual emails > but via AAA protocols against a DNS domain known AAA server > for the domain part of the email address. > > If you want to write a standards track RFC that all email addresses > used in any X.509v3 certificate MUST support an ACME style > challenge/reply email, then please do that, and seee if you get > thast through. If would invalidate a lot of solutions like > those wifi roaming ones. It WOULD NOT invalidate the ACP > solution, because as said (no several times) the ACP solution > can perfectly be set up to support this. It just does not > need to. > > Cheers > Toerless > > > Russ > > > > > > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert <t...@cs.fau.de > <mailto:t...@cs.fau.de>> wrote: > > > > > > Russ, > > > > > > Top posting re. your ACP vs. ACME question. > > > > > > ACP rfc822name are meant to be under control of the ACP network > operations. > > > aka: the ACP registrars could be controlling rfcSELF*@example.com > <http://example.com> mailboxes using > > > ACME S/MIME to get rfcSELF*@example.com <http://example.com> > certificates or IMHO easier control > > > the acp.example.com <http://acp.example.com> MTA. Just no > need/benefit to do this now IMHO: > > > > > > An ACP is a private network which is ideally isolated from other > > > ACP networks by use of private TA. Using the ACME rfc822name scheme > would > > > IMHO create a lot of attack components (all the MTA in the mail path > > > and domain names) if used acros the Internet - without benefits for > > > ACP. Of course, if it was all a private ACME setup within an > enterprise, > > > and using mailboxes and ACME is a popular choice - sure, why not. > > > But for private CA setups there are existing IMO easier options > > > (private CA VMs using EST or the like). > > > > > > IMHO public ACME CAwith S/MIME authenitcation could make sense > > > in the future to enable authentication across different ACP domains. > > > > > > Any network has links into other domains and today they are usually > > > unauthenticated, that could be solved IMHO fairly easily. > > > > > > "private" CA of ACP domain , lets call it acpCA signs all ACP certs. > > > Its own cert is not self-signed, but signed by ACME CA via S/MIME, > > > maybe email is rfcs...@example.com <mailto:rfcs...@example.com> (no > ACP IPv6 address in it) > > > > > > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > > After IKEv2 authenticates neigbor the followup ACP domain membership > > > step checks if the TA of the peer is acpCA. If yes, then peer > > > becomes ACP member, otherwise we have an authenticated signalling > > > channel to an interdomain / different CA peer. And that of course > > > would enable better/secure auto-configuration of such interdomain > > > links. > > > > > > This gives me good mix of security: Its still only relying on > > > well controlled private TA to get into ACP, but also doubles > > > at less secure but best available "Internet/Interdomain" > > > authentication. > > > > > > Cheers > > > Toerless > > > > > > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson > <mcr+i...@sandelman..ca <mailto:mcr%2bi...@sandelman.ca>> wrote: > > >>> > > >>> > > >>> Russ Housley <hous...@vigilsec.com <mailto:hous...@vigilsec.com>> > wrote: > > >>>> One cannot send email to the character string in this > specification, so > > >>>> it should not be carried in the rfc822name. > > >>> > > >>> You can send email to that character string if you configure the MX. > > >>> It was designed specifically to accomodate that. > > >>> > > >>> I objected at the time: I thought it was a stupid feature, that no > sensible IKEv2 daemon > > >>> was going to have to send/receive email. > > >>> > > >>> But, Toerless was paranoid that if we did anything at all out of the > > >>> ordinary, that the corporate CA people, in order to protect their > fiefdom, > > >>> would freak out and throw some huge roadblock in the way of > deploying the ACP. > > >>> > > >>> And, now have an ACME method past WGLC that does certificate > validation by > > >>> SMTP. > > >> > > >> Looking at the email certificate enrollment work in the ACME WG > (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device > that knows the private key could participate in such a protocol. How do you > see it working? > > >> > > >> Russ > > >> > > > > > > > > > > > >> _______________________________________________ > > >> Anima mailing list > > >> Anima@ietf.org <mailto:Anima@ietf.org> > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > -- > > > --- > > > t...@cs.fau.de <mailto:t...@cs.fau.de> > > -- > --- > t...@cs.fau.de <mailto:t...@cs.fau.de> > > _______________________________________________ > Anima mailing list > Anima@ietf.org <mailto:Anima@ietf.org> > https://www.ietf.org/mailman/listinfo/anima > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
