[Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.2.1

   Hash algorithms are not identified by themselves in certificates or
   BGPsec UPDATE messages.  They are represented by an OID that combines
   the hash algorithm with the digital signature algorithm as follows:

   o  The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the Public-Key
      Cryptography Standards #10 (PKCS #10) signatureAlgorithm field
      [RFC2986] or in the Certificate Request Message Format (CRMF)
      POPOSigningKey algorithm field [RFC4211]; where the OID is placed
      depends on the certificate request format generated.

The first paragraph talks of "certificates" but this last sentence talks
about "certificate request"s.  Are we trying to talk about both?

Section 7

The IANA considerations are perhaps not as accurate as they could be.
For example, we could say that the BGPsec Algorithm Suite Registry was
originally created by RFC 8208 and has been updated to refer to this
document, and similarly for the P256-SHA256 codepoint.
(Just moving the references over would seem to be even more appropriate
if this document were fully Obsoleting 8208.)

Appendix A

Do we want to note that the certificates are expired but the examples
are still useful within that constraint?  (They were valid at the time
RFC 8208 was published but it seems imprudent to try to assume that the
examples would always be valid, when writing a document such as this.)