Content-Type: multipart/alternative;
 boundary="------------GMZWaOPQV6ZBLdsZ2NUOWs9J"
Message-ID: <b87e7256-2c0a-48b8-ac74-52dd9cdd4c9c@web.de>
Date: Fri, 20 Sep 2024 21:58:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: cfrg@irtf.org
References: 
 <CAG2Zi20N98cxpgjfRe6gWw1SQEoux+5P3NhLBFUfUHk_udYeFg@mail.gmail.com>
 <AFC838DA-68C1-476C-8823-C3BF1E38CE39@csperkins.org>
 <CAG2Zi23hBZjJ==G0sRwyN+w9bH3ww=G3=MC3eHY+cExqd6X57Q@mail.gmail.com>
 <967BBF38-8C46-4ADC-BE41-47CAE7B7A235@csperkins.org>
From: =?UTF-8?Q?Bj=C3=B6rn_Haase?= <bjoern.m.haase@web.de>
In-Reply-To: <967BBF38-8C46-4ADC-BE41-47CAE7B7A235@csperkins.org>
UI-OutboundReport: notjunk:1;M01:P0:Y5hsd2V0YUU=;HsjOyCxOgQGbxU2kaLvtiQNhn9x
 uXONGHTgQ9CdfhsNOEk5yhZO4Lob4v6uQGiaNLosLYNhRBg/DtVyxtoq95CuTWfee2+3H6FFJ
 Rymn1U6+p8MiS/Rpvyv75h/ukM8jAodi4VwB9Lk51cLOv4UfaTdmm/NiuYpui3I0omNltWiE7
 R1ljT2Wrr5yNVBfITUGRTNV4An8D2ux/DOAKYUufVN7Ts2j3LiUxPYn4AexUxZkjYc6w70YSr
 V4Sm3kITeI+cdsamCX7/JrtUVVb3uXteJ86zYWI8+k5TFTYqK046KaIDSbwiT390xoZ+HdWeI
 p7pM6OXKkvN/2mXeBYYezRfz2rLcq72T0q/Ax/Ii1BsVGZ7jaiBtwuy8maRDZnpESIwXNgA5N
 7wdYTYMFFohkbwwIKTV/Cy5Ber6RZdexY1jhS147fi+lcLTuyfA2wiQZCzNhUHTvJBmeE8a0u
 1t5L35BNMaaTLbfg33ZPtBHgYKrhfwVKxU66LrHm7c6jVArVBVyaoGK5yWlJfwXRRrHxWa8yz
 KGcUTxZq8EVS90LuTpffIRP+N+5jhlLKZZuN0lHk6DoRtmhKQSmhNqa/sZ+cgVZBUtiPtrIjy
 NVBoj0hN5sdHtWNiXulBKiDADcYyUQCpk6TsMwCGPCw1Jg+O8GvAg1gBqDn2uPgxEyHU66kWI
 M8Baj2tKc1otJovPH2bkrFvBanq06x3OahMy3iZdDtx/HMIokvdYIhHOisjZd+xCxyhLfCycd
 jHo6tZak+VJIZAGqXMEp06SKP7n4JoHVAtt9Z7ZCcwJsa2oP7dAbAP7+/SLU4mrd3EvDhTORF
 93iBMLv1HGl31tPZ8K25Zf2Q==
Message-ID-Hash: MZ5ULPWSZAS3W7QMEGFJIFVVMAZPJQ77
Precedence: list
Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_Where_should_test_vectors_live=3F_//_Suggestion_w?=
 =?utf-8?q?ith_example_draft?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/cfrg/xVBZPEjWJ5M9tBWT40tq4w0kntI>

This is a multi-part message in MIME format.
--------------GMZWaOPQV6ZBLdsZ2NUOWs9J
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi to all,

as I did spend some time just yesterday with preparing test vectors in
JSON format for the upcoming next CPace draft version, I have today
patched my test vector generation scripts for including JSON in the
original text body of the ID in line with my today's suggestion for an
answer:
Suggested answer to the question "where should test vectors for CFRG
drafts live?":

"
1.) The test vectors SHALL live in the RFC and/or ID document
2.) Test vectors SHALL be made available in form of a textual "human-reada=
ble" format using base16 encoding.
Test vectors SHOULD also BE provided redundantly in a second format that i=
s machine-readable. It is RECOMMENDED to use a base64 encoding that
decodes to a JSON file as machine-readable format.
"

At

https://cfrg.github.io/draft-irtf-cfrg-cpace/draft-irtf-cfrg-cpace.html#na=
me-test-vector-for-cpace-using

you see how this possibly could look like.

What do you think about the approach taken there ? Maybe have a glance
at section B.1. to B.1.1.1 . For decoding the base64 sections you could
use your preferred online base64 decoder tool.

With the approach taken there we would avoid the difficulty of
maintaining a long-term link to some server.

I think for the end-user this might be even more convenient than having
a separate link. If test vectors are anyway machine-generated by scripts
(such as for CPace) integrating test vectors as part of the text body is
not really a lot of a burden. Also you maintain the textual context
specifying which exact test vectors are included.
The price that we would be paying is that we would have to accept some
redundancy (and have to check two outputs) and a bit longer RFC documents.

As comparison you could also look at the compiled total test vector file
for the CPace draft at

https://github.com/cfrg/draft-irtf-cfrg-cpace/blob/master/testvectors.json

I think that in this file it might be not really straight-forward to
locate the right section in the large file that applies to a given
subsection of the ID appendix.

I also would appreciate feedback regarding your opinion on old-fashioned
C-language constant tables as in B.1.8. What do you think? Are plain C
test vectors useful or should still we rather only use more modern JSON
as single format instead and forget about plain old C?

Yours,

Bj=C3=B6rn.


=2D-
Diese E-Mail wurde von AVG-Antivirussoftware auf Viren gepr=C3=BCft.
www.avg.com

--------------GMZWaOPQV6ZBLdsZ2NUOWs9J
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-=
8">
  </head>
  <body>
    <p>Hi to all,<br>
      <br>
      as I did spend some time just yesterday with preparing test
      vectors in JSON format for the upcoming next CPace draft version,
      I have today patched my test vector generation scripts for
      including JSON in the original text body of the ID in line with my
      today's suggestion for an answer:<br>
      <span style=3D"white-space: pre-wrap">
Suggested answer to the question "where should test vectors for CFRG draft=
s live?":</span></p>
    <pre wrap=3D"" class=3D"moz-quote-pre">"
1.) The test vectors SHALL live in the RFC and/or ID document
2.) Test vectors SHALL be made available in form of a textual "human-reada=
ble" format using base16 encoding.
Test vectors SHOULD also BE provided redundantly in a second format that i=
s machine-readable. It is RECOMMENDED to use a base64 encoding that
decodes to a JSON file as machine-readable format.
"</pre>
    <p>At <br>
      <br>
<a class=3D"moz-txt-link-freetext" href=3D"https://cfrg.github.io/draft-ir=
tf-cfrg-cpace/draft-irtf-cfrg-cpace.html#name-test-vector-for-cpace-using"=
>https://cfrg.github.io/draft-irtf-cfrg-cpace/draft-irtf-cfrg-cpace.html#n=
ame-test-vector-for-cpace-using</a><br>
      <br>
      you see how this possibly could look like. <br>
      <br>
      What do you think about the approach taken there ? Maybe have a
      glance at section B.1. to B.1.1.1 . For decoding the base64
      sections you could use your preferred online base64 decoder tool.<br=
>
      <br>
      With the approach taken there we would avoid the difficulty of
      maintaining a long-term link to some server. <br>
      <br>
      I think for the end-user this might be even more convenient than
      having a separate link. If test vectors are anyway
      machine-generated by scripts (such as for CPace) integrating test
      vectors as part of the text body is not really a lot of a burden.
      Also you maintain the textual context specifying which exact test
      vectors are included. <br>
      The price that we would be paying is that we would have to accept
      some redundancy (and have to check two outputs) and a bit longer
      RFC documents.<br>
      <br>
      As comparison you could also look at the compiled total test
      vector file for the CPace draft at <br>
      <br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/cfrg/draft-i=
rtf-cfrg-cpace/blob/master/testvectors.json">https://github.com/cfrg/draft=
-irtf-cfrg-cpace/blob/master/testvectors.json</a><br>
      <br>
      I think that in this file it might be not really straight-forward
      to locate the right section in the large file that applies to a
      given subsection of the ID appendix.<br>
      <br>
      I also would appreciate feedback regarding your opinion on
      old-fashioned C-language constant tables as in B.1.8. What do you
      think? Are plain C test vectors useful or should still we rather
      only use more modern JSON as single format instead and forget
      about plain old C? <br>
      <br>
      Yours,<br>
      <br>
      Bj=C3=B6rn.<br>
      <span style=3D"white-space: pre-wrap">
</span></p>
  <div id=3D"DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /><table style=3D"b=
order-top: 1px solid #D3D4DE;"><tr><td style=3D"width: 55px; padding-top: =
13px;"><a href=3D"http://www.avg.com/email-signature?utm_medium=3Demail&ut=
m_source=3Dlink&utm_campaign=3Dsig-email&utm_content=3Demailclient" target=
=3D"_blank"><img src=3D"https://s-install.avcdn.net/ipm/preview/icons/icon=
-envelope-tick-green-avg-v1.png" alt=3D"" width=3D"46" height=3D"29" style=
=3D"width: 46px; height: 29px;"/></a></td><td style=3D"width: 470px; paddi=
ng-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helveti=
ca, sans-serif; line-height: 18px;">Virenfrei.<a href=3D"http://www.avg.co=
m/email-signature?utm_medium=3Demail&utm_source=3Dlink&utm_campaign=3Dsig-=
email&utm_content=3Demailclient" target=3D"_blank" style=3D"color: #4453ea=
;">www.avg.com</a></td></tr></table><a href=3D"#DAB4FAD8-2DD7-40BB-A1B8-4E=
2AA1F9FDF2" width=3D"1" height=3D"1"> </a></div></body>
</html>

--------------GMZWaOPQV6ZBLdsZ2NUOWs9J--