Re: [Acme] Second AD Review: draft-ietf-acme-star

[Thomas Fossati <[e-mail]>]

Hi Roman,

Thank you very much for the review.

> I conducted as second AD review of draft-ietf-acme-star per the AD
> hand-off.  I have the following feedback:
>
> ** (From the first AD review) Per the issue of PS vs. Experimental
> status - I reviewed Section 5, Shepherd Write-up and the ML thread of
> the previous AD review
> (https://mailarchive.ietf.org/arch/msg/acme/ZWRzPxrWBrp_xjEn98A4HOBxkc4).
> From that I see there was one prototype implementation (from MAMI,
> thanks!) and a hackathon.  To following up, who has indicated interest
> in implementing this draft?

Provided that as editors we have no say in the matter (we just do as
told by the working group), a few additional data points:
- The MAMI implementation is being integrated with the OSM orchestrator
  [0] for NFV workloads;
- GSMA is considering ACME STAR as one of the reference solutions for
  handling encrypted content in CDNI (see also [1]);
- In the past few months there's been discussion related to the use of
  short-term certs for non-web use cases (see [2]), for example in the
  ANIMA control plane [3].

[0] https://osm.etsi.org
[1] https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https-delegation
[2] https://www.ietf.org/archive/id/draft-nir-saag-star-01.txt
[3] https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane

> ** Section 2.1.  Per "The bootstrap phase ends when the Id0 obtains a
> confirmation from the ACME CA that includes a star-certificate
> endpoint", what's a "star certificate endpoint" and how is that
> different than an "order URL for the issued STAR certificate" (per the
> previous paragraph)?

You are right that the wording is not precise enough.

We have modified Section 2.1., paragraph 3:

OLD:

    [...].  Per normal ACME processing, the IdO is given back an
    order URL for the issued STAR certificate to be used in subsequent
    interaction with the CA (e.g., if the certificate needs to be
    terminated.)

NEW:

    [...].  Per normal ACME processing, the IdO is given back an
    Order resource associated with the STAR certificate to be used in
    subsequent interaction with the CA (e.g., if the certificate needs to
    be terminated.)

And Section 2.1., paragraph 4:

OLD:

    The bootstrap phase ends when the IdO obtains a confirmation from the
    ACME CA that includes a star-certificate endpoint.

NEW:

    The bootstrap phase ends when the ACME CA updates the Order resource
    to include the URL for the issued STAR certificate.


> ** Section 2.2.  Per "The CA issues the initial certificate, typically
> when the authorization is done", what is the circumstance where the
> certificate is issued before the authorization?

Not sure how "typically" ended up here.

Section 2.2., paragraph 1:
OLD:

    The CA issues the initial certificate, typically when the
    authorization is done. [...]

NEW:

    The CA issues the initial certificate after the authorization
    completes successfully.  [...]

> ** Section 3.1.2.  Per "The server MUST NOT issue any additional
> certificates for this order beyond the certificate that is available
> for collection at the time of deletion": -- what is "time of
> deletion"?  Is that the same as the time order cancelation?  -- What
> does "beyond the certificate that is available for collection" mean if
> the text below this sentence says that accessing the star-certificate
> URL should return a 403 error?

Section 3.1.2., paragraph 4:
OLD:

    The server MUST NOT issue any additional certificates for this order,
    beyond the certificate that is available for collection at the time
    of deletion.

NEW:

    After a successful cancellation, the server MUST NOT issue any
    additional certificates for this order.

> ** Section 3.3.  The example shows a Link HTTP header but does not
> explain how it should be populated.

As per ACME spec (Section 7.1) the Link header points to the directory
resource:

    The "index" link relation is present on all resources other than the
    directory and indicates the URL of the directory.

> ** Section 7.  I didn't see any language in the Security Consideration
> about the impact/exposure of shifting to a model where certificate
> revocation doesn't occur.  In Section 1, [Topalovic] hints at
> potentially cover this topic, but the site used in the reference
> section didn't resolve for me.  It needs some treatment in the
> Security Considerations

Thanks for catching the broken ref, updated:

    [Topalovic]
               Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D.
               Boneh, "Towards Short-Lived Certificates", 2012,
               <http://www.ieee-security.org/TC/W2SP/2012/papers/
               w2sp12-final9.pdf>.


With regards to the Security Consideration, we have lifted the text from
(the currently expired) draft-nir-saag-star:

 7.1.  No revocation

    STAR certificates eliminate an important security feature of PKI
    which is the ability to revoke certificates.  Revocation allows the
    administrator to limit the damage done by a rogue node or an
    adversary who has control of the private key.  With STAR certificates
    expiration replaces revocation so there is a timeliness issue.  To
    that end, see also the discussion on clock skew in Section 4.1.

    It should be noted that revocation also has timeliness issues,
    because both CRLs and OCSP responses have nextUpdate fields that tell
    RPs how long they should trust this revocation data.  These fields
    are typically set to hours, days, or even weeks in the future.  Any
    revocation that happens before the time in nextUpdate goes unnoticed
    by the RP.

    More discussion of the security of STAR certificates is available in
    [Topalovic].

> ** Section 7.2.  The guidance in Section 7.2 seems appropriate for the
> identified privacy issue.  However, it also seems to apply to the more
> basic security issue of guessing the URL too.  -- Is there a reason
> why this isn't mentioned as a security issue too?  -- Why is the
> recommendation for a server to choose URLs in a non-guessable only a
> SHOULD and not a MUST?  Under what circumstances would it be advisable
> for the URLs to be guessable?

This is the same requirement level that we have in 8555 (Section 10.5);
we have added an explicit reference to avoid any future confusion.

Section 7., paragraph 5:
OLD:

    In order to avoid correlation of certificates by account, if
    unauthenticated GET is negotiated (Section 3.4) the server SHOULD
    choose URLs of certificate resources in a non-guessable way, for
    example using capability URLs [W3C.WD-capability-urls-20140218].

NEW:

    In order to avoid correlation of certificates by account, if
    unauthenticated GET is negotiated (Section 3.4) the recommendation in
    Section 10.5 of [RFC8555] regarding the choice of URL structure
    applies, i.e. servers SHOULD choose URLs of certificate resources in
    a non-guessable way, for example using capability URLs
    [W3C.WD-capability-urls-20140218].

> Editorial Feedback:

Please see https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-06 for
the details.

> ** Section 1.0  Per the sentence "The Id0 can terminate the automatic
> renewal before the natural deadline", what's a "natural deadline"?
> Isn't it a "negotiated deadline" or "negotiated renewal window"?

That's definitely better.  Fixed.

> ** Section 1.1  It seems odd to call out name delegation as the only
> formal use case.

It's not the only formal use case, but one that is maybe non-obvious, so
we think it's worth calling it out.

> ** Section 2.2.  Per Figure 1, this isn't explicitly noted as an
> example so it strikes me as inappropriate to include "72-hours" as the
> auto-renew period is negotiated (as it is so specific and could be
> read as normative).  Either call this an example or change "72 hours"
> to be something on the order of "short validity period".

Fixed.

> ** Section 2.3.  Figure 2 is included in Section 2.3 but is not
> referenced in the text.

Fixed.

> ** Sections 3.1.1, 3.1.2.  What is the role of the json blob after the
> first paragraph?  It isn't referenced in the text and doesn't have a
> figure number.

Removed -- in fact, the subsequent "attribute-name (optionality, type)"
makes it redundant.

> ** Section 3.1.1. Add a citation to "Section 7.1.3 of RFC8555" for
> notBefore and notAfter.

Fixed.

> ** Section 3.1.1.  Add the citation "Section 7.1.6 of RFC8555" to the
> sentence, "ACME defines the following values ..." to make it clear
> what part of ACME you are updating/extending.

Fixed.

> ** Section 3.1.1.  The first few paragraphs describing the new STAR
> items in the request as "attributes".  However, the last paragraph
> starting with "A STAR certificate ..." refers to "certificate" and
> "star-certificate" as a "key".  Be consistent.

Fixed (s/key/attribute/g).

> ** Section 3.2. Typo.  /The directory/the directory/

Fixed.

> ** Section 3.2.  As the meta field is being extended, add a reference
> to Section 9.7.6 of RFC8555.

Fixed.

> ** Section 3.2.  Use attribute or key to referrer to the additions to
> the "meta" field, not both.

Fixed.

> ** Section 3.2, 3.3.  Per the example, I recommend making this an
> explicit figure with a number that you reference instead of
> introducing it with a long sentence that ends with a colon.

Fixed.

> ** Section 3.4.  The recurrent-certificate-get is referred to as an
> attribute, but here it is called a key.  I recommend making this
> consistent.

Fixed (see above).

> ** Section 3.4.  Does the sentence "If the server accepts the request,
> it MUST reflect the key in the Order" mean that if the server accepts
> the request to support unauthenticated GETs, it will keep the
> recurrent-certificate-get=true in the order response?  If so, I'd
> recommend making this sentence a little clearer as without the assumed
> context of the section I didn't understand what it meant to "reflect a
> key".

Yes, your guess is correct. The term "reflect" is used in various places
in the base ACME spec to the same purpose.  Please, check if the
following is clearer:

OLD:

    If the server accepts the request, it MUST reflect the key in the
    Order.

NEW:

    If the server accepts the request, it MUST reflect the attribute
    setting in the resulting Order object.

> ** Section 3.5.1.  Per the array after the text "The notBefore and
> notAfter ... paragraph", why is this a JSON styled array?

No specific reason; it seemed to me like a convenient way to compactly
express both intervals' ordering and extent... It turns out Yaron also
didn't like it and took your hint to reformat the content into a table.

Cheers & thanks again for the great feedback!


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.