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

From: Thomas Fossati <[email-masked]>
Date: Mon, 1 Jul 2019 20:57:58 +0000

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.

---

From: <[email-masked]>
Date: Wed, 3 Jul 2019 12:13:12 +0000

Hi Roman,

> in implementing this draft?

I do think telcos are very interested in having a standardized solution to create short-term certificates based on ACME. For instance, in CDNI, we are looking to enable the delegation of secured traffic between an uCDN and a dCDN. ACME-STAR enables it and complies with CDNI requirements for controlling revocation. Moreover, as far as OpenCaching is concerned, CDNs will need open and standard interfaces to enable delegation from other parties. I believe that ACME-STAR needs to be in STD track.

Regards,
Frederic

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: [email-masked]
Date: Wed, 3 Jul 2019 23:46:10 +0000

Hi Roman:
You wrote:
>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?

The Streaming Video Alliance (SVA) (1) is implementing CDNI RFCs to enable delegation between CDNs, specifically, a  use case where a commercial CDN (uCDN) delegates to a CDN (dCDN) within an operator network or any other commercial CDN where the upstream CDN may not have presence. The SVA have also proposed extensions to existing CDNI RFCs (2).

WRT delegation between CDNI, there is currently a draft (3) in CDNI that adds CDNI's Metadata Interface to support HTTPS delegation. The metadata is specifically created to support delegation methods such as STAR (4) and sub-certificates (5).

In light of above usage it will be ideal if ACME STAR draft takes a standards track. This helps use of CDNI based implementations follow the "standards" track RFCs.

Regards
Sanjay 

1. https://www.streamingvideoalliance.org/technical-work/working-groups/open-caching/
2. https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/
3. https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https-delegation/
4. https://datatracker.ietf.org/doc/draft-ietf-acme-star/
5. https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/

-----Original Message-----
From: Acme [mailto:[email-masked]] On Behalf Of Roman Danyliw
Sent: Friday, June 21, 2019 7:58 AM
To: [email-masked]
Subject: [E] [Acme] Second AD Review: draft-ietf-acme-star

Hi!

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://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_acme_ZWRzPxrWBrp-5FxjEn98A4HOBxkc4&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=Z8DN4CFMEnApJigfCFWHcUdLeXhUaOlwT4RhVbdl37E&s=5yYWrxOs70ZpHqY0Ag_-8HyeI3ihZkqmQIM90e_T_Pc&e= ).  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?

** 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)?

** 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?

** 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.3.  The example shows a Link HTTP header but does not explain how it should be populated.

** 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

** 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?

Editorial Feedback:

** 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"?   

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

** 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".

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

** 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.

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

** 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.

** 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.

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

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

** 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.

** 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.

** 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".

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

_______________________________________________
Acme mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=Z8DN4CFMEnApJigfCFWHcUdLeXhUaOlwT4RhVbdl37E&s=XvyHQINuFMISJ3O8HjW9SC2jY9KVKgqAfn0OiLJW9CQ&e=

-----Original Message-----
From: Acme [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 3, 2019 8:13 AM
To: [email-masked]
Subject: [E] Re: [Acme] Second AD Review: draft-ietf-acme-star

Hi Roman,

> (https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_acme_ZWRzPxrWBrp-5FxjEn98A4HOBxkc4&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=yLAaMF-MGwjWB3Jp8WZmw8HRR93MAhg5RdwhPA5od70&s=0YR44tNW-n0As-n276FdL6fsPAJHssSl-AzoJ_OkJ78&e= ).

Regards,
Frederic

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
Acme mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=yLAaMF-MGwjWB3Jp8WZmw8HRR93MAhg5RdwhPA5od70&s=azc-m_m3NVHw4eGaWJcI1OoAOawOtTn2TtsX6_Hjonc&e=

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 11 Jul 2019 15:07:43 +0000

Hi Thomas!

> From: Thomas Fossati [mailto:[email-masked]]
> Sent: Monday, July 1, 2019 4:58 PM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Cc: Thomas Fossati <[email-masked]>
> Subject: Re: [Acme] Second AD Review: draft-ietf-acme-star
> 
> Hi Roman,
> 
> 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:

Given this information, I'm more comfortable with it being PS.

All of the new text in -06 or clarifications below address my concerns.  

Thanks for the revisions and clarifications.  I'll advance the draft.

Roman 

> With regards to the Security Consideration, we have lifted the text from (the
> currently expired) draft-nir-saag-star:
> 
>  7.1.  No revocation
> 
> 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:
> 
> Please see https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-06 for the
> details.
> 
> It's not the only formal use case, but one that is maybe non-obvious, so we
> think it's worth calling it out.
> 
> 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:
> 
> 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.
> 
> 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.