I have reviewed draft-ietf-drip-registries-27 as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

The summary of the review is Ready.

The text below details how the draft was improved to address my concerns, and includes
two optional suggestions. My security review of draft-26 mentioned that the draft was
ready, except for 4 points that could be fixed:

1. Linking the HHIT to the key via a 64 bit Orchid hash does not provide enough security.
When DNSSEC is not present, one must recommend a secure verification procedure.

2. The structure of the Canonical Registration Certificate in the HHIT RR is loosely
specified as "encoded using X.509 DER".

3. There is a tension between "implementing DNSSEC" and "publishing the HHIT record
just in time". If we rely on DNSSEC for security, it is more important to facilitate
DNSSEC signature than to try hide the certificate using "just in time" publishing.

4. Some risk that manually writing CBOR decoding code for the HHIT and BRID
RR Types could cause exploitable bugs.

In draft-27, the first issue is largely fixed. The security considerations have been
updated to make DNSSEC mandatory if the HHIT record contains a self-signed certificate;
and, if DNSSEC is not used, to require that clients "walk" the tree of certificates to
verify that it was properly signed by the relevant authority. This is good. My
only regret is that while the recommendations are sound, the text does not explain
why they are made -- i.e., because the 64-bit Orchid hash is too short to provide a
a secure linkage between the HHIT and the public key used by the UAS. Adding some
text to that effect would make the recommendations easier to understand.

The second issue is well addressed. The text in section 5.1.2 specifies
that "The Canonical Registration Certificate field is for a certificate endorsing
registration of	the DET. It MUST be encoded as X.509 DER [RFC5280]." The essential is
there. We may still argue that the text is a bit awkward, or that something like
"(see [draft-ietf-drip-dki])" would be useful, but the authors may or may not decide
to do that.

The tension between "just in time" and "DNSSEC" is also properly addressed by the new
text in section 7.2.

My mild concern about the coding risks inherent to complex CBOR syntax is not addressed.
It probably does not need to be directly addressed in this document, but it would be nice
if WG members somehow provided implementers with test vectors to verify the proper
decoding of HHIT and BRID RRs.