Re: [Tls-reg-review] [IANA #1135278] Re: Request to register value in TLS bar registry (tls-parameters)

[Смышляев Станислав Витальевич <[e-mail]>]

Hi Ben,

Thank you so much for your careful and detailed review (the other authors and I will reply to it in a separate message later in the corresponding Conflict Review thread- I agree with most of your comments)!

Regarding the IANA considerations of the draft-smyshlyaev-tls12-gost-suites document:
1) Those two early allocations for these two SignatureAlgorithms were made two and a half years ago (much earlier than RFC 8447) and are now currently widely used in many implementations in Russia (gostr34102012_256 and gostr34102012_512 are the only signature algorithms used in Russia, they are standardized in ISO/IEC 14888-3). Ben, could you please help us with finding an easy way of solving this issue together (without a specific Standards Track document just for two allocations)?..
2) The four other ciphersuites you asked about (0xC1, 0x03 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L etc.) list another draft as their reference, https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/ (the only difference in the name is "tls13" instead of "tls12").

Best regards,
Stanislav Smyshlyaev, Ph.D.
Deputy CEO, CryptoPro LLC

-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: Saturday, August 7, 2021 12:51 AM
To: Yoav Nir <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Коллегин Максим <[e-mail]>; Алексеев Евгений Константинович <[e-mail]>; Смышляев Станислав Витальевич <[e-mail]>; Смышляева Екатерина Сергеевна <[e-mail]>; Белявский Дмитрий <[e-mail]>
Subject: Re: [Tls-reg-review] [IANA #1135278] Re: Request to register value in TLS bar registry (tls-parameters)

Sorry to dig up an old thread...

On Fri, Feb 01, 2019 at 09:50:41PM +0200, Yoav Nir wrote:
> Hi, Amanda.  Inline.
> 
> Authors: please check my answers, especially about the supported groups.
> 
> > On 1 Feb 2019, at 21:32, Amanda Baber via RT <[e-mail]> wrote:
> 
> > 3) For the TLS SignatureAlgorithm registrations, can you confirm 
> > that we should  start from value 64, the beginning of the 
> > Specification Required range? (Also because the values are marked 
> > "Reserved" rather than "Unassigned," is it possible to make 
> > registrations here without an approved document? Is "Reserved," 
> > which in RFC 8126 means "unavailable for assignment," meant to 
> > indicate availability here, as it sometimes did for older 
> > registries?)

No, "Reserved" does not indicate availability here.

The SignatureAlgorithm registry is nominally closed, having been superseded by the SignatureScheme registry that effectively combines the SignatureAlgorithm and HashAlgorithm registries and is conveyed in the same protocol field.

https://datatracker.ietf.org/doc/html/rfc8447#section-15 is perhaps not as clear about this as it could be, but the intent was to not make additional allocations from this registry.

I think we need to convert these allocations into a handful of corresponding entries in the SignatureScheme registry, to avoid burning a sizeable chunk of the remaining SignatureScheme codepoint space.
Fortunately, they seem to only be paired with the 0x08 "intrinsic" hash algorithm, which would help reduce the number of allocations needed in the SignatureScheme registry.

-Ben

> Yes, starting at 64 is fine.
>