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
