Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F1BC169434 for ; Fri, 20 Sep 2024 12:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.407 X-Spam-Level: X-Spam-Status: No, score=-4.407 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org 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 4PXlHFNO4MdF for ; Fri, 20 Sep 2024 12:00:13 -0700 (PDT) Received: from mx1.mythic-beasts.com (mx1.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B02C13AE2C for ; Fri, 20 Sep 2024 12:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=D7yYKYJ+gYGNMywdfdT3+7Akauw1Q9AZG4zsFBaJR/A=; b=0YVLgIC6ykYaKGYHTTATHTk945 U5tkFERIaWt4CnUMK4Z1uRWxa9mNt54Sh8X//S/+llXNGK87t/C9tUawq+nKGxANGHiejoUzql1AB 2aLZRIsT8EnT7HoM49NgnV3mKHw+XRhavYVBXKZQNMJ+5nk1nSBPkhV19zYhXzIa2jQeQwPGxHTki GHL8twqtPlrgdJLvx4IAtu9ThKnR2CrlgZ7LCH+DrRczMDmkdU/wNHkaDWai7XIB5/RwA5zLyBEDt NqnzSyqsvPNBHVAO70tI4AWK4sPVB2Q8vDs6IJIhDXuhFpbym2k0SP4gDeE7ins8uGETg3nKnzuyy Y7dGG8iQ==; Received: by mailhub-cam-d.mythic-beasts.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1srirU-001hXh-3Q; Fri, 20 Sep 2024 20:00:12 +0100 From: Colin Perkins To: Christopher Patton Date: Fri, 20 Sep 2024 20:00:08 +0100 X-Mailer: MailMate (1.14r6065) Message-ID: <967BBF38-8C46-4ADC-BE41-47CAE7B7A235@csperkins.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_52691707-AEDF-4734-B758-7B50A4428510_=" Embedded-HTML: [{"plain":[1029,1622],"uuid":"426B1463-E05B-4A7B-8094-2908702EFF9B"}] X-BlackCat-Spam-Score: 9 Message-ID-Hash: G7RYUSANHSFQLZIXFRH5MDKP6WDFEIG3 X-Message-ID-Hash: G7RYUSANHSFQLZIXFRH5MDKP6WDFEIG3 X-MailFrom: csp@csperkins.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: CFRG , RFC Editor X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_Where_should_test_vectors_live=3F?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=_MailMate_52691707-AEDF-4734-B758-7B50A4428510_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, For links from RFCs to GitHub, I=E2=80=99ve copied the RFC Editor to get = a = definitive ruling. My feeling is that we wouldn=E2=80=99t want links to = personal GitHub pages, but it might make sense to link to GitHub repos = owned by the research group since they=E2=80=99re perhaps more likely to = be = long-term stable. Presumably the github links would be informative = rather than normative? For the additional resources, look at = https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/ or = https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/ for = examples (in the Document section). The datatracker lets you, where I = think =E2=80=9Cyou=E2=80=9D is the relevant RG/WG chair, specify the foll= owing for = each draft: faq, github_org, github_repo, github_username, gitlab_repo, = gitlab_username, jabber_log, jabber_room, mailing_list, = mailing_list_archive, related_implementations, repo, slack, tracker, = webpage, wiki, yc_entry, yc_impact, zulip (each can occur multiple = times). Cheers, Colin On 20 Sep 2024, at 18:28, Christopher Patton wrote: > Colin, > > What would be the contents of the "Additional resources" field? Would = > it > just be a link to GitHub? Ideally the RFC itself would tell you where = > to > get test vectors: do you think it's inappropriate for the RFC itself = > to > link to GitHub? > > Chris P. > > On Fri, Sep 20, 2024 at 10:03=E2=80=AFAM Colin Perkins = > wrote: > >> Hi, >> >> The datatracker has an =E2=80=9CAdditional resources=E2=80=9D field fo= r each = >> draft, that >> can be used to cross-reference to GitHub repos, etc. >> >> Colin >> >> On 20 Sep 2024, at 1:17, Christopher Patton wrote: >> >> Hi CFRG, >> >> It occurred to me today that our drafts often have human-friendly = >> test >> vectors that look something like this: >> https://datatracker.ietf.org/doc/html/rfc9180#appendix-A.1.1 >> >> These aren't super convenient for a machine. In theory you could = >> write a >> script that downloads https://www.rfc-editor.org/rfc/rfc9180.txt and >> write a parser to pull out the test vectors, but does anyone really = >> do >> this? Luckily for RFC 9180 we have a JSON version to work with = >> instead: >> >> https://raw.githubusercontent.com/cfrg/draft-irtf-cfrg-hpke/refs/heads= /master/test-vectors.json >> >> How do folks feel about pointing to machine readable test vectors = >> from an >> RFC in lieu of producing human-friendly, but machine-unfriendly in = >> the >> appendix? Suppose for example an RFC had a pointer to a JSON blob = >> somewhere >> on datatracker. Is this feasible/desirable? >> >> Thanks, >> Chris P. >> >> _______________________________________________ >> CFRG mailing list -- cfrg@irtf.org >> To unsubscribe send an email to cfrg-leave@irtf.org >> >> --=_MailMate_52691707-AEDF-4734-B758-7B50A4428510_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

For links from RFCs to GitHub, I=E2=80=99ve copied the RF= C Editor to get a definitive ruling. My feeling is that we wouldn=E2=80=99= t want links to personal GitHub pages, but it might make sense to link to= GitHub repos owned by the research group since they=E2=80=99re perhaps m= ore likely to be long-term stable. Presumably the github links would be i= nformative rather than normative?

For the additional resources, look at https://datat= racker.ietf.org/doc/draft-ietf-lamps-csr-attestation/ or https://data= tracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/ for examples (in the= Document section). The datatracker lets you, where I think =E2=80=9Cyou=E2= =80=9D is the relevant RG/WG chair, specify the following for each draft:= faq, github_org, github_repo, github_username, gitlab_repo, gitlab_usern= ame, jabber_log, jabber_room, mailing_list, mailing_list_archive, related= _implementations, repo, slack, tracker, webpage, wiki, yc_entry, yc_impac= t, zulip (each can occur multiple times).

Cheers,
Colin



On 20 Sep 2024, at 18:28, Christopher Patton wrot= e:

Colin,

What would be the contents of the "Additional resources" field? Woul= d it just be a link to GitHub? Ideally the RFC itself would tell you wher= e to get test vectors: do you think it's inappropriate for the RFC itself= to link to GitHub?

Chris P.

On Fri, Sep 20, 2024 at 10:03=E2=80= =AFAM Colin Perkins <csp@csperkin= s.org> wrote:

Hi,

The datatracker has an =E2=80=9CAdditional resources=E2=80= =9D field for each draft, that can be used to cross-reference to GitHub r= epos, etc.

Colin


On 20 Sep 2024, at 1:17, Christopher Patton wrote:

Hi CFRG,

It occurred to me today that our drafts often have human-friendly te= st vectors that look something like this:

These aren't super convenient for a machine. In theory you could wri= te a script that downloads https://www.rfc-editor.org/rfc/rfc9180.txt= and write a parser to pull out the test vectors, but does anyone really = do this? Luckily for RFC 9180 we have a JSON version to work with instead= :

How do folks feel about pointing to machine readable test vectors fr= om an RFC in lieu of producing human-friendly, but machine-unfriendly in = the appendix? Suppose for example an RFC had a pointer to a JSON blob som= ewhere on datatracker. Is this feasible/desirable?

Thanks,
Chris P.

_______________________________________________
CFRG mailing list -- c= frg@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org

--=_MailMate_52691707-AEDF-4734-B758-7B50A4428510_=--