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