Carl,
thanks for the review and comments. responses inline below.
Steve
Hello Stephen, thanks for writing this up. I only had a few comments (first
grammatical/flow, then on the content):
Is the missing the 2119 boilerplate intentional?
no, fixed.
In the Status section, there is a missing double quote:
work in progress."
should be
"work in progress."
fixed.
I think the 'So' is extraneous here:
1. Introduction
Certificates are issued by CAs. So the top level differentiation in
this analysis is whether the CA that mis-issued a certificate did so
maliciously or not.
How about:
Because CAs issue certificates, the top level differentiation in this analysis
is whether the CA that mis-issued a certificate did so maliciously or not.
done
You are missing a period at the end of the last sentence in 2.1.1.1.
fixed.
There is a double comma in 2.2.1.2 (and not to get into the finer points of RFC
Grammar, there is a mix of double single-quotes and single double-quotes
throughout (with the count tilting higher towards the former); Was that
intentional?)
not intentional, fixed.
There appears to be a nested note in Note 5; this strikes me as odd, but not
necessarily bad.
fixed.
---------------------------------------
On the subject of semantic mis-issuance in a non-malicious Web PKI Context
(Section 2.1):
A non-malicious Web PKI CA may issue certificates for which it is authorized by the CA CPS
yet, is unauthorized by the Subject. This is very similar to 2.2.1.1.1, except that the
party receiving the certificate is "authorized" (thus not quite fitting your
description of bogus). A specific case of this is where the Subject has set up a CAA record
clearly stating the Subject's policy towards certificate issuance and a non-malicious CA
whose CPS states that it does not respect CAA records (in accordance with CABF BRs) issues a
certificate anyway. An additional example are certificates issued when validated simply
using email addresses such as the live.fi [1] cert from earlier this year, or a number of
other email domains as described here->[2].
If this type of per-company policy distinction ought to earn a mention in this
document, I believe that it would fit under 2.1.1. Here is my suggested text:
-----BEGIN-----
2.1.1.1
... all clients.
The Log, when receiving a recently signed pre-certificate SHOULD assist in
detection of bogus certificates by checking CAA records [rfc6844] and sending a
report to the URL as specified in the iodef property.
we'll have to think more about our examples. I'm not sure that 6844 has
gained enough traction to
cite it here, but I'll defer to others on this issue.
... If a bogus ...
2.1.1.1.2. Benign third party Monitor
...
When the Monitor receives a recently signed pre-certificate it MAY then check
the CAA [rfc6844] record and send a report to the URL as specified in the iodef
property. A Monitor MAY also check certificates for compliance with the HPKP
header [rfc7469] of a Subject site or browser HPKP headers, mismatches SHOULD
be reported to the Subject, if the Subject has a relationship with the Monitor,
or as specified in the report-uri directive of the HPKP header.
-----END-----
I think the cert pinning checks are good ones to add as additional
actions by a Monitor.
We'll include them in a future rev.
I put the CAA validation on the log more strongly than the monitor because individual
logs ought to be getting the SCTs right before the time of issuance (in a matter of
seconds or minutes) rather than such a time as when a Monitor asks which may be at a much
later time (e.g. "recently signed").
if CAA records are widely used, then I agree with your prioritization,
but ???
Alternatively, these additional checks for semantic correctness may belong
better in the set of kent-trans-*-validation-cert-checks documents? Perhaps in
new text as section 3.3?
those docs try to enumerate the checks required by the DV and EV docs.
these added checks are
not mentioned in those CABF specs, so I think it will be better to
consider adding text about
cert pinning (and, maybe, CAA records) to this doc instead.
Slightly off topic, but since it's referenced in this threat doc:
draft-kent-trans-domain-validation-cert-checks-00 2.1.6.B refers to section
9.2.6 of the CABF-DV BRv1.2.3; such a section of the BRs does not exist.
Whoops. we'll have to fix that next time, thanks for the note.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
