Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Töma Gavrichenkov]

Peace,

On Fri, Jun 19, 2020 at 8:31 PM Eric Rescorla  wrote:
> My reasoning is that (as above) these algorithms are generally of
> low interest and that requiring community review for code point
> registration has the result of consuming quite scarce resources
> in the service of making the algorithms which are being registered
> marginally clearer.

I sort of agree but I can't help wondering if the IETF would then
manage to process the flow of technical erratas, corrections and -bis
documents, which the current community review process is aiming to
avoid.

--
Töma

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

As I mentioned earlier, in response to "we need this on standards track" I have 
produced a very short draft that would remove that requirement:
   https://www.ietf.org/id/draft-hoffman-dnssec-iana-cons-00.txt
It covers both DS records and NSEC3 records, which have similar issues with 
hash algorithms. It also has an appendix that reflects Ekr's thoughts that 
maybe this all should be "specification required".

If the WG wants, this short draft could be a WG document.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Василий Долматов]

> 19 июня 2020 г., в 21:17, Dick Franks  написал(а):
> 
> On Fri, 19 Jun 2020 at 18:12, Paul Hoffman  > wrote:
> On Jun 19, 2020, at 9:26 AM, Eric Rescorla  > wrote:
> > What's your reasoning for why there needs to be community review before 
> > there is a code point assigned?
> 
> Historically, the quality of algorithm descriptions in early drafts has been 
> variable. What the author considers sufficient and obvious, another might 
> not. Also, review gives folks a chance to say things like "your test vectors 
> appear wrong", "having test vectors would be really useful", and so on. 
> 
> How does any of that apply?
> The algorithm in this case is specified by another standards organisation and 
> is what it is.
> Community review did not find the incorrect test parameters in RFC5832 / GOST 
> R34.10-2001.

In the given case it is worth referring to RFC7091/GOST R34-10.2012
but the statement remains the same.



dol@


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop