Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document

[Brian E Carpenter <[e-mail]>]

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 <[e-mail]> 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 [e-mail] (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 <[e-mail]> wrote:
>>>>
>>>>
>>>> Russ Housley <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/anima
>>
>>
>> -- 
>> ---
>> [e-mail]
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>