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 and therefore does not match the semantics of RFC 5280. 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. -Ekr On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <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. > > 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 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> 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 > mailboxes using > > > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier > control > > > the 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 (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> wrote: > > >>> > > >>> > > >>> Russ Housley <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 > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > -- > > > --- > > > t...@cs.fau.de > > -- > --- > t...@cs.fau.de > > _______________________________________________ > 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
