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.
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"
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.
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.
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.
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."
Section 10: "
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 list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
