Russ,
On 10/25/22 2:20 PM, Russ Housley wrote:
Paul:
Document: draft-ietf-lamps-rfc3709bis-06
Reviewer: Paul Kyzivat
Review Date: 2022-10-25
IETF LC End Date: 2022-10-28
IESG Telechat date: ?
Summary:
This draft is on the right track but has open issues, described in the review.
Issues:
Major: 0
Minor: 1
Nits: 2
1) MINOR: In Section 4.1 (Extension Format):
The following:
"CAs SHOULD use the one-way hash function that is associated with the certificate
signature to compute the hash value, and CAs MAY include other hash values."
introduces the possibility that a client might not support *any* of the
provided hash algorithms. This seems bad.
RFC3709 didn't have this problem because it required that an SHA-1 hash be
included and supported.
This can be fixed by changing "CAs SHOULD" to "CAs MUST".
We are seeing a few signature algorithms that are not following the hash-then-sign
pattern. I'm not sure how to allow the signature on the certificate to use one of them
(like EdDSA) when one has to know a lot about the algorithm details to determine which
hash is used internally. As you say, the "CAs MUST" would require the
certificate issuer to do that research. Do others have an opinion?
Well then, how about picking some algorithm (to replace SHA-1) that
clients must support and that must be used in cases when cert signature
algorithm can't be used?
Or worst case, discuss what is to be done by a client who doesn't
support any of the offered hash algorithms.
2) NIT: From IdNits:
** Downref: Normative reference to an Informational RFC: RFC 1952
I think it would be ok to change the reference to Informative.
RFC 1952 is already in the downref registry, so it is not a concern. I wish
id-nits checked the registry...
Ah, OK.
Thanks,
Paul
3) NIT: Typos
In Section 3 (Logotype Data):
s/then each image objects/then each image object/
In Section 7 (Image Formats):
s/The following table lists many commons/The following table lists many common/
s/requirements these image formats/requirements for these image formats/
s/the client will receive response/the client will receive a response/
(The last one above appears twice.)
In Section 10 (Privacy Considerations):
s/cache logotype data is cached/cache logotype data/
All of these nits have been corrected in my edit buffer. Thanks for the
careful read.
Russ
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
