On 28-Jun-20 03:52, 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.
I don't see a requirement in RFC5280 that the email address in an rfc822name must be reachable, or that it must belong to the private key holder. Brian > > Russ > > >> On Jun 27, 2020, at 1:40 AM, Toerless Eckert <[email protected]> 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 [email protected] (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 <[email protected]> >>>> wrote: >>>> >>>> >>>> Russ Housley <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/anima >> >> >> -- >> --- >> [email protected] > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
