Re: [Sidrops] draft-ietf-sidrops-signed-tal and RFC8630 'optional comment section'?

Ties de Kock <tdekock@ripe.net> Tue, 27 September 2022 09:13 UTC

Return-Path: <tdekock@ripe.net>
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 C0EF7C1524C0 for <sidrops@ietfa.amsl.com>; Tue, 27 Sep 2022 02:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
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 OWdhqmeropWP for <sidrops@ietfa.amsl.com>; Tue, 27 Sep 2022 02:13:14 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 B03ECC14CF05 for <sidrops@ietf.org>; Tue, 27 Sep 2022 02:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=RyA7u+703QSm06keH/4/MGSKnzbLDq3M15rjh3XEVr8=; b=M4SY38CN9s+6Cr/ZDFQMlfDS ktkpnQL+n78CidGFjma6JI1HNmGVv2IayJS8YHfoC/JYnSQCmRnAy6q46nF6+NqnhrnKjPBWyxNWu GTX+xEeLrNalQ124IdpHr1STZwa9rIx6xFB69e96JUmuipxPZ38w320JaHOdGdF1G8IzO0sJ4eySF BKH1iM6em26x7axl/9RH3PNhphd8MA782/Uleq/AWXY5+uL4mVkyObGUkEEPlL5mkiriF/yCSn6HN RBfA3lA6uK75VpTbVs1bmFeoZU/uXrZ03oaqSmSlXCe3+lCjsuhp0Bc3mF6MypsW8jW2jlrQEDe0v SZO1lt7REw==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:47688) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1od6eM-0008ap-6o; Tue, 27 Sep 2022 11:13:10 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1od6eM-0006Y1-3r; Tue, 27 Sep 2022 09:13:10 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <YzK7IEXlYXE/sOQJ@snel>
Date: Tue, 27 Sep 2022 11:13:09 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <415E2CD0-C637-40FB-A466-11B2831A90DD@ripe.net>
References: <YzK7IEXlYXE/sOQJ@snel>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e19d97e416fcff961458b864cbfa5cadf3
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/nPtGXVsH1ztexJJhEqOuDy3FaPA>
Subject: Re: [Sidrops] draft-ietf-sidrops-signed-tal and RFC8630 'optional comment section'?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2022 09:13:17 -0000

Hi Job,

> On 27 Sep 2022, at 10:58, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> Hi all,
> 
> Recent versions of draft-ietf-sidrops-signed-tal introduce the notion of
> transforming (while validating) a TAK file into a RFC 8630 TAL file.
> 
> However I noticed might be a lack of feature parity:
> 
> the RFC 8630 format allows for optional comments (text prefixed with
> '#'), in addition to the URIs and subjectPublicKeyInfo.
> 
> On the other hand, the draft-ietf-sidrops-signed-tal-11 TAK Object
> Definition only provides for inclusion of URIs and subjectPublicKeyInfo.
> 
> Perhaps it is good to extend the TAKey SEQUENCE definition to allow for
> an optional AI5String to encapsulate a comment section?

What use cases do you have in mind? I think it worthwhile to generate a comment
in a tal generated from TAKs to trace its provenance. On the other hand, it is
practically impossible for RPs performing a certificate update via the TAK
object to process a free text comment in an object.

I can think of some use cases ("message from the TA to an RP maintainer") but
let's flush those out and see if they are not covered by RSC already.

Afterwards, we can see how that would influence processing (e.g. how long does
the comment need to persist to accept it, how do we restrict the character set,
etc).

Kind regards,
Ties

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops