Deb,
Thanks for reading the doc and providing comments prior to our next
planned rev.
My responses are inline below.
Steve
All,
This is my first post on list ever, so be gentle :)
General: This is actually an attack model with an analysis of
detection and consequence. Perhaps the name could be changed to
reflect that.
I agree. We'll change it for the next rev.
General: 2.2’s outline should follow 2.1’s outline. Move ‘Malicious
or conspiring third party Monitor’ to section 2.2.1.3 and remove it
from 2.2.1.1.3 and 2.2.1.2.1. It may be complete either way, but it
is more likely to look complete if it is symmetric.
We'll try to better align the outlines between 2.1 and 2.2. But, because
the CA assummptions
differ, it may not be possible to make the outlines completely parallel
(without introducing
redundant sections that may make reading harder in a different way).
We'll review the placement of 2.2.1.1.3 and 2.2.1.2.1 in the context of
outline realignment.
General: Remove the references to the Notes in Sections 2 and 3.
They will stand alone.
do you mean the notes will stand alone? I agree that the notes can stand
alone, but I worry that
folks reading the sections that now contain those forward references may
not tie them back to
the relevant sections without the forward references.
Section 2.1.1.1.1: Change to:
“If a Subject is tracking the log(s) to which a certificate was
submitted, and is performing self-monitoring, then it will be able to
detect a bogus (pre-) certificate and request revocation. In this
case, the CA will make use of the log entry, supplied by the Subject
to determine the serial number of the mis-issued certificate, and
investigate/revoke it.”
We'll make the suggested change.
Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 : Make the “If
there are many logs, it may not be feasible for a Subject to track all
of them” a note in Section 4 (it is sort of Note 1 currently).
we can add text to state this potential problem, in the indicated
sections. However, it is
the Monitor function that tracks logs. Only when a Subject self-monitors
is the specific
text you cited correct. So, we'll substitute Monitor for Subject in your
text, OK?
Section 2.1.1.1.2: Change this in a similar manner to 2.1.1.1.1, for
the same reasons.
OK.
Section 2.1.1.2.2: How will gossiping detect this? The Log owner
issues the SCT, but doesn’t actually put the certificate into the
log. How is this detectable by gossiping? Not like an attacker is
going to submit that certificate to multiple logs. He just wants the SCT.
I based this comment on the projected capabilities of a gossip
mechanism, the details of which
are yet to be agreed upon. I think the notion is that multiple Auditors
query log(s) to determine
if the returned log entries and STHs represent consistent views. I'll
try to generate some better
text here, and to discuss the Audit function in the intro, to help clarify.
Section 2.1.2: Does the 3rd party monitor have a role in the case
where the certificate isn’t logged? Should that fact be stated?
Perhaps a sentence to that effect in Section 2.1.2.3 would be in order?
When a cert is not logged, no Monitor, even a self-monitoring Subject,
will detect issuance of a
bogus cert based on Monitor functions. That's what this section is
intended to convey, but we can
try to improve the wording.
Section 2.1.2.1: Either remove the last sentence in the
parenthetical, or work it into the paragraph without the parenthetical.
OK.
Section 2.2.1.2: Add a section on Self-monitoring Subject and a
section on benign third party Monitor.
Section 2.2.1.1.3 and 2.2.1.2.1: Combine these into Section 2.2.1.3
called malicious or conspiring third party monitor.
I don't follow your comment above. it doesn't match the outline for
section 2.1. I think
2.2.1.2.1 should be subsumed under 2.2.1.2, but 2.2.1.1.1 seems
appropriate as an enumeration
of cases under 2.2.1.1.
Section 3, Syntactic checks: We need to think about whether this
makes sense. This paper gets much simpler w/out it. Currently not
included in rfc6962bis.
6962bis failed to define what a mis-issued cert is, even though the term
is the focus of the
CT effort. When I asked Ben about this last year I initially thought
that only bogus certs
(as we now define them) were mis-issued. But, Ben stated that a failure
to adhere to the DV
or EV cert profiles would be considered mis-issuance for certs of that
genre. I agree that
this should counted as mis-issuance, and if we intend to expand CT
beyond Web PKI certs,
then syntactic mis-issuance is even more important. That's why we have
two candidate syntactic
cert profiles posted, and why I proposed a mechanism to allow a
submitter to declare what
type of cert is being submitted to a log. I also suggest that logs be
allowed to optionally
check submitted (pre-) certs against an declared type, perform
appropriate checks if they
can (and are willing) and record the results in the SCT.
Section 4, Notes: These are issues that will need to be addressed. I
would make a more descriptive name and keep them numbered.
OK. We'll add more text for each note and use outline numbering for them.
Section 4, Note 1: Make this two items. First: How are new logs
discovered by monitors? Second: how does a subject know which logs
the monitor is checking?
Good point. we'll do that.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
