[CFRG] Re: Where should test vectors live?

[Björn Haase <[e-mail]>]

Hello to all,

I have just worked on JSON testvector generation for the upcoming new version of the CPace draft. (https://github.com/cfrg/draft-irtf-cfrg-cpace/blob/master/testvectors.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?

So far we have integrated ANSI-C test vectors in the draft. I did try to do similarly for JSON, however it seems that for JSON we will not be able to follow the “max number of characters per line” requirement
for I-D and RFC.

The challenge might  be twofold.

1.) For actual protocols, such as CPace we will be having *lots* of different test vectors for different cipher suites. In the machine-readable format the test-vector user will have to find the appropriate set of vectors for his use-case.
2.) How to make sure that an I-D (respectively RFC) has a fixed 1:1 link to an associated binary file.

If there were an option to integrate it in the XML in ignored sections that would be fine, however there might be lots of different frameworks around that automatically generate the XML from other sources, such as markdown. We likely would have to fix them.

Yours,

Björn


Mit freundlichen Grüßen | Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: [phone]
[e-mail] |  www.ehla.endress.com 





Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

 



Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
 



Von: Watson Ladd <[e-mail]>
Gesendet: Freitag, 20. September 2024 03:10
An: Christopher Patton <cpatton=[e-mail]>
Cc: CFRG <[e-mail]>
Betreff: [CFRG] Re: Where should test vectors live?


On Thu, Sep 19, 2024, 5:18 PM Christopher Patton <cpatton=[e-mail]<mailto:[e-mail]>> 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?

Why not in ignored elements (not sure how to do)in the XML source? This might take some tools team input.

Thanks,
Chris P.

_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>