Hi,
I've been going over the mailing list archives and version -24 of the
syslog-sign draft. In general version -24 is a big improvement, but I
noticed a couple of things that weren't fixed in -24 yet.
(I haven't checked all the emails yet, so expect more emails
today or tomorrow. In hindsight, doing several smaller draft updates
instead of one big update would have made tracking the comments
easier :-).
Section 4.2 says "The fields MUST be provided in the order listed";
Section 5.3.2 should include the same statement.
Sections 4.2 and 5.3.2 should either say that new SD parameters MUST
NOT be added unless a new Protocol Version is defined, or describe
how to handle them. The former would be easier :-)
Section 5.2, key blob type 'P': RFC 4880 don't clearly define what an
"OpenPGP certificate" is. Probably should add something like "(a
Transferable Public Key as defined in [RFC4880], Section 11.1)".
Section 5.2, key blob type 'K': does not say how the public key is
encoded. Probably should say something like "For the OpenPGP DSA
signature scheme, this field contains the DSA prime p, DSA group order
q, DSA group generator g, and DSA public-key value y, encoded as four
multiprecision integers (see [RFC4880], Sections 5.5.2 and 3.2)."
(Or if you want to use ASN.1, "..., this field contains a DER-encoded
SubjectPublicKeyInfo structure that MUST use the id-dsa OID and MUST
contain the DSA domain parameters [RFC3279]").
Sections 4.2.8 and 5.3.2.8: the text doesn't say how the signature is
encoded (what's the input to Base64 encoding). Probably should say
something like "For the OpenPGP DSA signature scheme, this field
contains the DSA values r and s, encoded as two multiprecision
integers (see [RFC4880], Sections 5.2.2 and 3.2), concatenated, and
then encoded in base 64 [RFC4648]". (Or if you want to use ASN.1,
"..., this field contains a DER-encoded Dss-Sig-Value structure
[RFC3279]").
Sections 5.2 and 5.3.2.7: actually, the payload block fragment is
*NOT* base64 encoded; it's included as is (since per 5.2 the payload
block contains only printable ASCII, there's no need to base64 encode
the fragment).
Section 9.*: '"IETF Consensus" policy defined in [RFC5226]'
should be '"IETF Review" policy defined in [RFC5226]'
Section 9.2: this text still allows only values 0-9 for the hash
algorithm field (Section 4.2.1 now allows a-z and A-Z too).
References NIST800.90 and RFC3414 should be informative rather
than normative.
Reference RFC5280 has extra space in title ("...Certificate<SP><SP>and...")
(idnits warns about this)
Section 2, RFC 2119 boilerplate should be spelled "key words"
instead of "keywords" (idnits warns about this)
Best regards,
Pasi
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
