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

sanjay.mishra@verizon.com Wed, 03 July 2019 23:46 UTC

Return-Path: <sanjay.mishra@verizon.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7550F120179 for <acme@ietfa.amsl.com>; Wed, 3 Jul 2019 16:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXZW1XhDhwzw for <acme@ietfa.amsl.com>; Wed, 3 Jul 2019 16:46:12 -0700 (PDT)
Received: from smtpout2-tdc.verizon.com (smtpout2-tdc.verizon.com [137.188.104.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96248120173 for <acme@ietf.org>; Wed, 3 Jul 2019 16:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1562197572; x=1593733572; h=to:cc:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:from; bh=ljvB68+UPkMxm+kTIUt8WyGyLzZ5C0L2G31qNPR2Itg=; b=DO5rie0kHw0rvFoNuU/IlMHd9zOo65blvVnAkcgzTcdqMIUsyFwDos5t INPT+GcEal+611tx22GU3ZRaL45nHH0KWDzqMh6Jpbow1HpwdELUnIC/0 3SGI/xYWY+3Gygz+RD4hqS9Ax7VkQSExsci95Oh+rBNkhWzjldLJ7BFVz 0=;
From: sanjay.mishra@verizon.com
Received: from tbwexch05apd.uswin.ad.vzwcorp.com ([153.114.162.29]) by smtpout2-tdc.verizon.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 03 Jul 2019 23:46:11 +0000
Received: from tbwexch09apd.uswin.ad.vzwcorp.com (153.114.162.33) by tbwexch05apd.uswin.ad.vzwcorp.com (153.114.162.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 19:46:10 -0400
Received: from tbwexch02apd.uswin.ad.vzwcorp.com (153.114.162.26) by tbwexch09apd.uswin.ad.vzwcorp.com (153.114.162.33) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 19:46:10 -0400
Received: from tbwexch02apd.uswin.ad.vzwcorp.com ([153.114.162.26]) by tbwexch02apd.uswin.ad.vzwcorp.com ([153.114.162.26]) with mapi id 15.00.1473.003; Wed, 3 Jul 2019 19:46:10 -0400
To: Roman Danyliw <rdd@cert.org>
CC: "acme@ietf.org" <acme@ietf.org>
Thread-Topic: [Acme] Second AD Review: draft-ietf-acme-star
Thread-Index: AQHVME+pqBBnRgjCJECNx8HuPcPLiaa4zf2wgADAPzA=
Date: Wed, 03 Jul 2019 23:46:10 +0000
Message-ID: <48ff477949ce48da907fd31d3133924c@tbwexch02apd.uswin.ad.vzwcorp.com>
References: <AA4F08D4-5890-4ADA-93FD-CF6DFD631884@arm.com> <15913_1562155993_5D1C9BD9_15913_189_1_1BD328329726EF4E91AE924BB1B4CB9E64276408@OPEXCAUBM24.corporate.adroot.infra.ftgroup>
In-Reply-To: <15913_1562155993_5D1C9BD9_15913_189_1_1BD328329726EF4E91AE924BB1B4CB9E64276408@OPEXCAUBM24.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.144.60.250]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/3XeDDrpd8SHf4GC5gBQUsvOMX4o>
Subject: Re: [Acme] Second AD Review: draft-ietf-acme-star
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 23:46:17 -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:acme-bounces@ietf.org] On Behalf Of Roman Danyliw
Sent: Friday, June 21, 2019 7:58 AM
To: acme@ietf.org
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. Typo.  /The directory/the directory/

** 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
Acme@ietf.org
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:acme-bounces@ietf.org] On Behalf Of frederic.fieau@orange.com
Sent: Wednesday, July 3, 2019 8:13 AM
To: acme@ietf.org
Subject: [E] Re: [Acme] Second AD Review: draft-ietf-acme-star

Hi Roman,

> 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=yLAaMF-MGwjWB3Jp8WZmw8HRR93MAhg5RdwhPA5od70&s=0YR44tNW-n0As-n276FdL6fsPAJHssSl-AzoJ_OkJ78&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?

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.

_______________________________________________
Acme mailing list
Acme@ietf.org
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=