From nobody Fri Aug 14 09:46:08 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2383F3A1184 for ; Fri, 14 Aug 2020 09:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=cloudflare.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 Rn4onvKGo8nK for ; Fri, 14 Aug 2020 09:45:57 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ECA13A0FE1 for ; Fri, 14 Aug 2020 09:45:57 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id g11so2843497ual.2 for ; Fri, 14 Aug 2020 09:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ir6DYXR3X0+MzOBI76/MRwg9NupEHD7/HlnE/EoR/bc=; b=ERTZ266h1ovfS8ziaq1cPFtTTF7iFxQ3JcTlASVqn91F5krpQnVBj4S5+STtwUOJ47 +RHyUCzwwCBfZ4NRKoQptpJw0Fihy1L5U+iJzmOYe47rXYZxkWu+W32FMN4v/yoit3Ms QU2O00Cv1O3vwu1U4svWJl6DZiJyb3OP2XTjw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ir6DYXR3X0+MzOBI76/MRwg9NupEHD7/HlnE/EoR/bc=; b=SV2eyIGvNiJhFO2ilIn+iNho5B2Y2U3Kruz6likLmqAq1jBBYoxx9/RfBzOcqhpqdd oGTRNFSYRdywN6ymIXdtxcLKu6vqiaSbvjBLfLgznXK0xPiKlR81ur2N8X4+3D86xDk/ bprI8+JLdG84b22XnwFwxaVSNxOcfZH7hw2qK0SZmFsF0Z28HWKWyHJ9Wmw99k2tjoe5 wyTI6qNMyrwQDR2s7oU+CGF9TU+yiSTiai8UxIxX9WkD7KfdiRar192kJ/7dYNKc7Kwj NRQdhHP38uBTfgrGFT1M/357YgbYRefnAIh1hyEyMNWPdGbS9czgPRh+T3Ph0Bmv3one qtPQ== X-Gm-Message-State: AOAM533DuayYrehkQWQogaoY6/WjpFa+VtEmM3G6RwqmaInCgSAbCRB6 wai/JVHjWcID6ft1I0/tzsHkgG01IBeBVwVQz8DDig== X-Google-Smtp-Source: ABdhPJxkJxaKxrwRbjVJRMGyA7zHuHsRyJYIcQQuQ6ASuGNA5bt74+jfHypI5TLCarDGfMQkLQBnXwfkL7C3P94F2Ps= X-Received: by 2002:ab0:66d4:: with SMTP id d20mr1958772uaq.97.1597423555769; Fri, 14 Aug 2020 09:45:55 -0700 (PDT) MIME-Version: 1.0 References: <0d9bb2eb-aed6-f1cb-30fa-859448bfb6ef@riseup.net> In-Reply-To: <0d9bb2eb-aed6-f1cb-30fa-859448bfb6ef@riseup.net> From: Nick Sullivan Date: Fri, 14 Aug 2020 09:45:39 -0700 Message-ID: To: =?UTF-8?Q?Sof=C3=ADa_Celi?= Cc: "" Content-Type: multipart/alternative; boundary="00000000000099225005acd92710" Archived-At: Subject: Re: [TLS] comments on draft-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 16:46:06 -0000 --00000000000099225005acd92710 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the review, Sof=C3=ADa. I'm looking forward to the PR. Once t= hat lands we'll submit a version of the doc with WGLC#2 comments incorporated. Nick On Thu, Aug 13, 2020 at 12:35 AM Sof=C3=ADa Celi wro= te: > Dear, list, > > Sorry for sending this past the last call. > > Few comments on the draft, which are: > > - On Section 1: > > "For clarity, we will refer to the certificate issued by the CA as a > "certificate", or "delegation certificate", and the one issued by the > operator as a "delegated credential" or "DC"." > > I think this sentence can be their own paragraph, so it does not get > lost with the rest of the text. It will be good to clarify as well the > usage of 'credential', 'delegation', 'delegator' terms used through out > the document. It will be really nice to clarify the term 'credential' as > it sometimes seems to be used to refer to 'delegated credential', and > sometimes to the 'Credential' struct. > > - On section 7.3 > > "Delegated credentials do not provide any additional form of early > revocation. Since it is short lived, the expiry of the delegated > credential would revoke the credential. Revocation of the long term > private key that signs the delegated credential also implicitly > revokes the delegated credential." > > Not sure how the implicit revocation will work. It is my understanding > that the sole way to check that a DC is revoked is by verifying its > valid time, and this is the way that renders it 'invalid'. > Maybe, the DC is valid until it expires regardless if the long-term > private key is revoked, as I don't see a way to mark the DC invalid when > the long-term private key revokes. But perhaps, I'm understanding this > incorrectly. > > In that case, how the DC signed by a revoked key will be treated? Should > it wait until they expire to render them completely explicitly invalid? > > > I have other minor editorial changes that I'll send as a PR. > > Thanks! > > > > > > -- > Sof=C3=ADa Celi > @claucece > http://claucece.github.io/ > Cryptographic research and implementation at many places, but mainly at > Cloudflare > FAB9 3EDC 7CDD 1198 DCFD 4558 91BB 6B45 6F44 2D02 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000099225005acd92710 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the review, Sof=C3=ADa. I'm looking forw= ard to the PR. Once that lands we'll submit a version of the doc with W= GLC#2 comments incorporated.

Nick

On Thu, Aug 13, 2= 020 at 12:35 AM Sof=C3=ADa Celi <cherenkov@riseup.net> wrote:
Dear, list,

Sorry for sending this past the last call.

Few comments on the draft, which are:

- On Section 1:

"For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one= issued by the
operator as a "delegated credential" or "DC"."

I think this sentence can be their own paragraph, so it does not get
lost with the rest of the text. It will be good to clarify as well the
usage of 'credential', 'delegation', 'delegator' te= rms used through out
the document. It will be really nice to clarify the term 'credential= 9; as
it sometimes seems to be used to refer to 'delegated credential', a= nd
sometimes to the 'Credential' struct.

- On section 7.3

"Delegated credentials do not provide any additional form of early
revocation. Since it is short lived, the expiry of the delegated
credential would revoke the credential. Revocation of the long term
private key that signs the delegated credential also implicitly
revokes the delegated credential."

Not sure how the implicit revocation will work. It is my understanding
that the sole way to check that a DC is revoked is by verifying its
valid time, and this is the way that renders it 'invalid'.
Maybe, the DC is valid until it expires regardless if the long-term
private key is revoked, as I don't see a way to mark the DC invalid whe= n
the long-term private key revokes. But perhaps, I'm understanding this<= br> incorrectly.

In that case, how the DC signed by a revoked key will be treated? Should it wait until they expire to render them completely explicitly invalid?


I have other minor editorial changes that I'll send as a PR.

Thanks!





--
Sof=C3=ADa Celi
@claucece
http://claucece.github.io/
Cryptographic research and implementation at many places, but mainly at
Cloudflare
FAB9=C2=A03EDC=C2=A07CDD=C2=A01198=C2=A0DCFD=C2=A0=C2=A04558=C2=A091BB=C2= =A06B45=C2=A06F44=C2=A02D02

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000099225005acd92710--