Dear Michael, Sorry for a very long delay, as your review was the only one I thought there was not enough interest in this document.
On Wed, Feb 2, 2022 at 12:04 AM Michael StJohns <m...@nthpermutation.com> wrote: > On 2/1/2022 3:35 PM, Tim Wicinski wrote: > > All > > We were reviewing the Working Group Last Call for this, and we received no > comments. We know there was interest in at least moving this forward, but > even Warren concurred we can't send this to the IESG unless there are folks > saying they feel it is ready to be published. > > Thanks > > tim > > > Hi Tim - > > Since you ask, I don't think it's ready to go forward. Section 2 is > particularly opaque. > > Section 2.1 - Provide the ASN1 that explains what's going on by adding the > prefix to a 64 byte GOST public key. Ideally identify the various OIDs > that match to the key format, and to the signature format. > Done > Section 2.2 - How does the private key in the first part of the example > get you to the public key in the second? > > The Base 64 in the DNSKEY appears to give you this value: > > 5E 46 7A 4F EA 90 F6 D7 8E 32 C0 3F 60 AF A4 4F > 31 0B 86 E3 0F 4E C6 20 81 DC B6 6F EB 1F CC 9E > AD 1F D7 A7 8B 38 8C 5F 78 23 32 75 19 23 2A E7 > 48 87 21 2E 3B A9 F3 1A 72 F9 45 39 97 51 32 8F > > Which appears to be an unparameterized GOST public key which I assume > matches the private key. That may be a valid key or not, but saying that > explicitly would be useful. Or at least "The following DNSKEY RR > contains the encoded GOST public key paired with this private key - see xxx > for the key pair generation logic" > Done > To fix all this, start from a normal (PEM or PKCS8 or PKCS12 or X509) > representation of an example key pair and work from there to map to/form > DNSKEY, DS and RRSIG records. > > The algorithm number is specified as 23 here and other places, and that's > so that the examples could be calculated, but if the IANA doesn't issue > them 23 as the number (and they probably won't) most of the examples will > have to be redone with the final values. This is a cart/horse problem and > I'd recommend that the IANA do an early assignment of the signature and > digest algorithm values and that the document be redone with the final > values prior to IESG submission to prevent a round trip during RFC > publication. > Yes, this is a possible way forward. > Sections 3.1 and 4.1 - show your work. Show the actual data being hashed > or signed so that someone else coming along can verify that a) you did the > encoding properly, and b) the hashes match or the signatures match. This > is especially important with algorithms which lack broad international > implementation. > It's the most problematic part for me nowadays. So I provided a reference to my fork of LDNS I used for the DNS part of work and a link to a reference implementation of GOST algorithms. If you think it's not enough, I will try to remember what I did and regenerate the examples with intermediate steps. > Section 5 - these should refer to the GOST specification (e.g. "MUST be > 512 bits per [GOSTxxx]"). As stated, this could be something peculiar to > this spec rather than the underlying cryptographic primitive. > Done. > Section 6.1 - huh? In any case, we generally don't have single subheader > sections - move the text up. I think this is supposed to be "The support > of this cryptographic suite in DNSSEC-aware systems is OPTIONAL. Systems > that do not support these algorithms may ignore the RRSIG, DNSKEY and DS > records created with them." > Done. > Section 10: " > Sorry, didn't get :( > I hope this helps - > > Mike > > > ---------- Forwarded message --------- > > All > > With draft-ietf-dnsop-dnssec-iana-cons now in AUTH48 state, it's time to > move this document along as well. > > This starts a Working Group Last Call for draft-ietf-dnsop-rfc5933-bis, > "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource > Records for DNSSEC" > > Current versions of the draft is available here: > https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-07.html > > The Current Intended Status of this document is: Informational > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please speak > out with your reasons. > > Because of the American holiday, we're going to run the last call process > a few days long. This Working Group Last Call will end on: 10 December > 2021 > > thanks > tim > > _______________________________________________ > DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- SY, Dmitry Belyavsky
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
