Subject: [Acme] Alexey Melnikov's Discuss on draft-ietf-acme-star-09: (with DISCUSS and COMMENT)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Sun, 29 Sep 2019 09:29:28 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-acme-star-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-star/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this well written document.

I have one small issue that I would like to discuss before recommending approval of this document:

Section 6.4 and 6.6 don’t seem to specify IANA registration procedure for new subregistries.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1.1. Name Delegation Use Case

The proposed mechanism can be used as a building block of an efficient
name-delegation protocol, for example one that exists between a CDN or a cloud
provider and its customers [I-D.ietf-acme-star-delegation]. At any time, the
service customer (i.e., the IdO) can terminate the delegation by simply
instructing the CA to stop the automatic renewal and letting the currently
active certificate expire shortly thereafter. Note that in this case the
delegated entity needs to access the auto-renewed certificate without being in
possession of the ACME account key that was used for initiating the STAR
issuance.

Can you explain the last sentence? I am reading “in this case” as the delegated
entity needs access to renewed certificate once delegation is cancelled, which
doesn’t make sense. Please let me know if I misunderstood.

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 29 Sep 2019 19:03:12 +0000

Hi Alexey,

Thank you very much for your comments.

> Section 6.4 and 6.6 don’t seem to specify IANA registration procedure for new

Are you saying we should say explicitly what the contents of the new
sub-registries are?  If so, something like the following would work for you:

Section 6.4., paragraph 4:
OLD:

      +-----------------------+------------+--------------+-----------+
      | Field Name            | Field Type | Configurable | Reference |
      +-----------------------+------------+--------------+-----------+
      | start-date            | string     | true         | RFC XXXX  |
      | ...

NEW:

    Initial contents: The fields and descriptions defined in
    Section 3.1.1.

      +-----------------------+------------+--------------+-----------+
      | Field Name            | Field Type | Configurable | Reference |
      +-----------------------+------------+--------------+-----------+
      | start-date            | string     | true         | RFC XXXX  |
      | ...

Section 6.6., paragraph 4:
OLD:

             +-----------------------+------------+-----------+
             | Field Name            | Field Type | Reference |
             +-----------------------+------------+-----------+
             | min-lifetime          | integer    | RFC XXXX  |
             | ...

NEW:

    Initial contents: The fields and descriptions defined in Section 3.2.

             +-----------------------+------------+-----------+
             | Field Name            | Field Type | Reference |
             +-----------------------+------------+-----------+
             | min-lifetime          | integer    | RFC XXXX  |
             | ...

If this is not what you want, please guide me as I'm slightly lost :-)

"in this case" refers to "name delegation", sorry for the confusion.

When using the default POST-as-GET method to retrieve the cert, the delegated
entity should be in possession of the account key to sign the request.
However, sharing key material between the delegating and the delegated party
is not ideal -- in fact, it's what we want to avoid in the first place here.

What about:

Section 1.1., paragraph 1:
OLD:

    [...]
    certificate expire shortly thereafter.  Note that in this case the
    delegated entity needs to access the auto-renewed certificate without
    being in possession of the ACME account key that was used for
    initiating the STAR issuance.

NEW:

    [...]
    certificate expire shortly thereafter.

    Note that in the name delegation use case the delegated entity needs
    to access the auto-renewed certificate without being in possession of
    the ACME account key that was used for initiating the STAR issuance.

Cheers, thanks!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 30 Sep 2019 09:59:32 +0100

Hi Thomas,

> On 29 Sep 2019, at 20:03, Thomas Fossati <[email-masked]> wrote:
> 
> Hi Alexey,
> 
> sub-registries are?

I was talking about rules for adding new values to these 2 subregistries. E.g. “Expert Review”, “Specification Required”, “IETF Review”, etc.

Listing initial registrations would be useful as well.

Best Regards,
Alexey

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 30 Sep 2019 09:17:40 +0000

Hi Alexey,

> I was talking about rules for adding new values to these 2
> subregistries. E.g. “Expert Review”, “Specification Required”,
> “IETF Review”, etc.

Ah, thanks for the clarification!

I don't see a reason why this new registries should be treated
differently from all other ACME registries and sub-registries
(i.e., Specification Required), so I'd say:

Section 6.1., paragraph 2:
OLD:

    o  ACME Order Auto Renewal Fields (Section 6.4)
    o  ACME Directory Metadata Auto Renewal Fields (Section 6.6)

NEW:

    o  ACME Order Auto Renewal Fields (Section 6.4)
    o  ACME Directory Metadata Auto Renewal Fields (Section 6.6)
    All of these registries are administered under a Specification
    Required policy [RFC8126].

Rich, Yoav: would that work for you?

Cheers, t