Subject: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Feb 2021 15:13:48 -0500

We have struggled with brski-ae to deal with how the pledge can pin a thing
from the pledge-agent to prove proximity.

It feels that something like either Delegated STAR could work well.
Or, if not that, and we are using TLS, then draft-ietf-tls-subcerts-10
Failing that, we need to create some kind of JWT, or CWT artifact which the
Registrar uses to bless the pledge-agent.

We have spoken about gathering the voucher-request artifact from the pledge
with the pledge-agent initiating the communication.  That is, the pledge
is passive for this, and the pledge-agent initiates.  Some would call
this PUSH, if they are thinking about things from the pledge point of view.
But, the pledge-agent has to PULL the voucher-request from the pledge,
and then PUSH the voucher-request to the RA...

So, I want to suggest that sections 5.1 and 5.2 be renamed.

I find the PULL/PUSH terminology confusing.  I recognize that the
directionality that is implied by the PULL/PUSH is based upon, I thought,
whether the RFC8366 voucher is retrieved by the pledge, or provided to the
pledge.  But, in section 5.1, I think that it's called PULL because the
communication with the RA?

I guess I am much more interested in the 5.2 interaction!
That it could support, for instance, smart-phone + NFC, is very interesting.
I believe that it should not be session based (i.e. object security, not TLS
or EDHOC).

[email-masked] wrote:
    >         Title : An ACME Profile for Generating Delegated STAR
    > Certificates Authors

    > Abstract: This memo proposes a profile of the ACME protocol that allows
    > the owner of an identifier (e.g., a domain name) to delegate to a third
    > party access to a certificate associated with said identifier.  A
    > primary use case is that of a CDN (the third party) terminating TLS
    > sessions on behalf of a content provider (the owner of a domain name).
    > The presented mechanism allows the owner of the identifier to retain
    > control over the delegation and revoke it at any time by cancelling the
    > associated STAR certificate renewal with the ACME CA.  Another key
    > property of this mechanism is it does not require any modification to
    > the deployed TLS ecosystem.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide