Last Call Review of draft-ietf-acme-caa-06
review-ietf-acme-caa-06-secdir-lc-orman-2019-04-11-00
| Request | Review of | draft-ietf-acme-caa |
|---|---|---|
| Requested revision | No specific revision (document currently at 10) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2019-04-10 | |
| Requested | 2019-03-27 | |
| Authors | Hugo Landau | |
| I-D last updated | 2019-11-26 (Latest revision 2019-06-20) | |
| Completed reviews |
Secdir IETF Last Call review of -06
by Hilarie Orman
(diff)
Genart IETF Last Call review of -06 by Roni Even (diff) Secdir Telechat review of -08 by Hilarie Orman (diff) |
|
| Assignment | Reviewer | Hilarie Orman |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-acme-caa by Security Area Directorate Assigned | |
| Reviewed revision | 06 (document currently at 10) | |
| Result | Has nits | |
| Completed | 2019-04-11 |
review-ietf-acme-caa-06-secdir-lc-orman-2019-04-11-00
Security review of
CAA Record Extensions for Account URI and ACME Method Binding
draft-ietf-acme-caa-06
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
comments.
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.
Hilarie