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

[Roman Danyliw <[e-mail]>]

Hi Thomas!

> -----Original Message-----
> From: Thomas Fossati [mailto:[e-mail]]
> Sent: Monday, July 1, 2019 4:58 PM
> To: Roman Danyliw <[e-mail]>; [e-mail]
> Cc: Thomas Fossati <[e-mail]>
> Subject: Re: [Acme] Second AD Review: draft-ietf-acme-star
> 
> 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_xjEn98A4HOBxk
> c4).
> > 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

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 

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