Last Call Review of draft-ietf-acme-caa-06

Request Review of draft-ietf-acme-caa
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-04-10
Requested 2019-03-27
Authors Hugo Landau
Draft last updated 2019-04-11
Completed reviews Secdir Last Call review of -06 by Hilarie Orman (diff)
Genart Last Call review of -06 by Roni Even (diff)
Secdir Telechat review of -08 by Hilarie Orman (diff)
Assignment Reviewer Hilarie Orman 
State Completed
Review review-ietf-acme-caa-06-secdir-lc-orman-2019-04-11
Reviewed rev. 06 (document currently at 10)
Review result Has Nits
Review completed: 2019-04-11


	                Security review of
     CAA Record Extensions for Account URI and ACME Method Binding

Do not be alarmed.  I have reviewed this document 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

The subject of this document is DNS records describing certificate
issuance policies and how the policies can be made more granular
through the use of two new parameters: accounturi and validationmethods.
The first parameters designates particular accounts that can act
as CAs for a domain, the second parameter names the methods that can
be used for validation.

It took me almost an hour to realize that "accounturi" was "account uri".
It looked like some fancy foreign word.  "He was not merely an
accountant, he was an acounturi from a noble hereditary line."

Moving on, the document claims that the only effect of the new
parameters is to narrow the ways in which a certificate should be
issued.  There are no additional security measures.  Bad actors can
still be bad, men can remain in the middle.  The new parameters are
there for the use of good actors.

I am not convinced that all of the items in section 5 really are
"security considerations".  The increased granularity is not in itself
a security meaure.  Some of the items relating to validation methods
and DNSSEC are security consideration.

As nearly as I can tell, there are no security problems.