[Sidrops] Re: Deb Cooley's No Objection on draft-ietf-sidrops-signed-tal-15: (with COMMENT)
Deb Cooley <debcooley1@gmail.com> Wed, 15 May 2024 21:53 UTC
Return-Path: <debcooley1@gmail.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3999C1CADED; Wed, 15 May 2024 14:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0esCc74g7WjG; Wed, 15 May 2024 14:53:45 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB7CC18DBB8; Wed, 15 May 2024 14:53:45 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id e9e14a558f8ab-36c7ee71ebaso2986055ab.2; Wed, 15 May 2024 14:53:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715810024; x=1716414824; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=OSfKeq8ZXifuFvFbr6l4sz1lIp8zZ+YzyjjY0gbRFRc=; b=FEu+stFDq4zJPwaUU9GFZAuPSafqB/bLREXvVd/p/mGXsm6fIImY9qrVkKiUE5S+0J pWfYzGNu0rKTRec6tYkMjN0bcXHFJlQctpGVspuur8XpnAzjT614pjHHqnNySXmzIwMU gMDcar1npvk9npigkGsK7wKabQEd4I7Odx1ihOE9nRCLGXJFoVnOqMjXYqHioETUHPV8 VxCOvSYC/5NqbW5ypqZ0SpkzmpGPlfw08L+yenxy8097Cpg8AJDboDs4/WDVVPU5wQmY dLPT/jcOYGLESsH0E/kkaNfjWgutOjr5E9THfp/ikexLb87w02NHXhV4D6oBKVXKZZQ9 v7Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715810024; x=1716414824; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OSfKeq8ZXifuFvFbr6l4sz1lIp8zZ+YzyjjY0gbRFRc=; b=FsMm5jE43xRIblwiSvKmszvXQAb+IfjJUksFQ8LkQsHMe9BK1CDS0kMtIQTTkRwSem /eZCiXlQ/aSkcNn2qUfO7eLbwO7wwz7CB4auX20+M4InrqULaDEO2faK0LUFGG9dOqqO Oi/F11Kgx82X0mxzevKLqoHcXxMSUYxAuKRejRWY9hD2ojF0u/zE9QjheAI56Es3DoC1 vR4j2hbastn0PavqsqF4v8xa2Sl+o+3eP0Ld+I16rlRhOHJU1pyjQpqz0wtE7tfQEc+a yRaAUBricINVJRHfuoIk1mUUx+v9YkdSDRJoFU5dYsGkdR3E63kU6QvsQel64DDmqn7x tpBQ==
X-Forwarded-Encrypted: i=1; AJvYcCUGkGTJyVGcAm9OyuiWM201kPxVMIZcLZOuRJfz3tNsaoLO2HHHOyfpH674NqsTckOzzvBS1ww75BIldg+hkvidojZtrg4is7yfQmAFr77uFPGIN7Mf1i2SOFjPIBRFTKwYbT6uRkmJ7jJKlm3dFNQsq6E87Q6HKSFOBhM7ndQUhJElhQBzpwfMlNIJlL53jZk=
X-Gm-Message-State: AOJu0YynYsN+ECFTdC1A7UXAEKbhop6lkQ93vINdb2C+ZRk5hcMKX8vK egqHA3rpt1qbVkm9YE4jbEhoZOjgbHQf+0/TCcN/1dFeCJR5v8gHVmUhoWnF08jcPU2kB0KKx5/ s0Yzk8aQ72w+kEfXnRTVKMzBMww==
X-Google-Smtp-Source: AGHT+IEkGrf177kWocEsg8BBBH57sCjhHQ7Cl+nuQm2dC/yTZqt5J8E2txTT2uBG/pwcasWa9Q+5Dimj+DrXRQ7W4zc=
X-Received: by 2002:a05:6e02:1a0a:b0:36c:5143:73d6 with SMTP id e9e14a558f8ab-36cc14aa150mr220691075ab.16.1715810024214; Wed, 15 May 2024 14:53:44 -0700 (PDT)
MIME-Version: 1.0
References: <171568759189.40367.7885327637125706120@ietfa.amsl.com> <ZkQmwYFrsHYPzvSW@TomH-498551.lan>
In-Reply-To: <ZkQmwYFrsHYPzvSW@TomH-498551.lan>
From: Deb Cooley <debcooley1@gmail.com>
Date: Wed, 15 May 2024 17:53:25 -0400
Message-ID: <CAGgd1OeTWLGx_=NZSNo2e7_F8nw5BNZXQN=1xeSd+tR5zhb3nQ@mail.gmail.com>
To: Deb Cooley <debcooley1@gmail.com>, The IESG <iesg@ietf.org>, draft-ietf-sidrops-signed-tal@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, keyur@arrcus.com, housley@vigilsec.com
Content-Type: multipart/alternative; boundary="000000000000fedb460618852690"
Message-ID-Hash: MQ7WW2L55WMDXJJW2WLMKJ2N7GRCRU22
X-Message-ID-Hash: MQ7WW2L55WMDXJJW2WLMKJ2N7GRCRU22
X-MailFrom: debcooley1@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-sidrops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Sidrops] Re: Deb Cooley's No Objection on draft-ietf-sidrops-signed-tal-15: (with COMMENT)
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yJoNPbsSsRZCEv-ucitFY3zOtiM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Owner: <mailto:sidrops-owner@ietf.org>
List-Post: <mailto:sidrops@ietf.org>
List-Subscribe: <mailto:sidrops-join@ietf.org>
List-Unsubscribe: <mailto:sidrops-leave@ietf.org>
Those changes are perfect. Thank you for all of that work to change 'key' to 'public key', 'private key' and 'key pair'. I'm sort of shocked at how often it wasn't just 'public key'. I also like the change of roll to rollover. Deb Cooley On Tue, May 14, 2024 at 11:06 PM Tom Harrison <tomh@apnic.net> wrote: > Hi Deb, > > Thanks for your review. > > On Tue, May 14, 2024 at 04:53:11AM -0700, Deb Cooley via Datatracker wrote: > > General: This is just me, no action required (I am a PKI person, so > > I am pedantic on occasion). I find the use of 'key' vice 'public > > key' to be a bit confusing. There should be a distinction between > > 'private keys' and 'public keys' and the generic us of 'key' doesn't > > do that (in fact, I think most people think of 'key' as synonymous > > with 'private key'). I gather from reading this draft and poking > > around at the RPKI RFCs that the use of 'Key' is common terminology, > > so it would be confusing to change that now. If there was ever an > > opportunity to clarify, it would be nice (maybe in the intro, para > > 2?). > > The draft has been updated to use 'public key', 'private key', and > 'key pair' wherever 'key' has been used unqualified. (Although other > RPKI documents in at least some instances use 'key' unqualified to > refer to the public key (per your comment), I don't think using the > more precise terms here will cause any problems in that respect.) > > > Section 2, para 3: This is confusing? "... will first validate the > > TAK object, if present. ... If the TAK object lists only a current > > key....continues processing as it would in the absence of a TAK > > object.... if the TAK object includes a successor key... continues > > processing as it would in the absence of a TAK object." Does > > processing of the TAK object happen elsewhere? While other > > processing occurs? If there is a TAK object, then why do you need > > the phrase 'continues processing as it would in the absence of a TAK > > object'? > > Just for context, the idea here was to rely on the existing behaviour > of a given RP, rather than trying to describe what RPs do in the usual > course of things in a categorical sense, due to the risk of that > description not capturing all use cases. However, the confusion in > the text is a problem, and the risk is probably not significant, so > this has been changed to: > > If the TAK object lists only the current public key, then the RP > continues processing as it would in the absence of a TAK object. > If the TAK object includes a successor public key, the RP starts a > 30-day acceptance timer for that key, and then continues standard > top-down validation with the current public key. > > An updated version of the document is attached for reference (includes > updates from secdir review and other IESG review). There is also a > diff from the previous version (-15), and a diff for the changes for > this review on its own. > > -Tom >
- [Sidrops] Deb Cooley's No Objection on draft-ietf… Deb Cooley via Datatracker
- [Sidrops] Re: Deb Cooley's No Objection on draft-… Tom Harrison
- [Sidrops] Re: Deb Cooley's No Objection on draft-… Russ Housley
- [Sidrops] Re: Deb Cooley's No Objection on draft-… Deb Cooley