Ben,
... Ok, that's what _you_ do, but 5280 describes a long list of cert
path validation rules
and your doc just says that these can be relaxed. It does not
prohibit a log from
performing the full set dictated by PKIX and X.509 path
validation procedures, nor
does it provide guidance of which subset SHOULD/MUST be performed.
Absent such guidance
different log operators can legitimately perform different checks,
resulting in chaos.
I don't believe it will result in chaos, but anyway, the purpose of
checking signatures on log submissions is to combat spam. I don't
think we should tightly define exactly what checks are performed to
that end, because that's a great way to leave yourself unable to
defend against some kind of unforeseen spam. We can certainly clarify
that. I've added a ticket.
Perhaps I have not been clear enough in specifying my concern. A CA (or
cert Subject) submitting
a cert chain to a log needs to know, unambiguously, what checks will be
performed. This specificity
is needed to ensure that submissions to multiple logs will all be
accepted or rejected (assuming
that the root CA for the chain is advertised as acceptable by the log
operator).
...
If we had a agreed-upon requirements doc that explained why the
serial number is
critical, and if it discussed the impact on CAs that may use
serial number management
techniques that preclude pre-determining the serial number
assigned to a cert, then
we would be in good shape. But we don't. So, I think we may have a
serious problem
with this aspect of the precert model.
The purpose of CT is to detect mis-issuance so that it can be
rectified. As already explained, some revocation mechanisms require
the serial number of the revoked cert. I don\t think we need a
separate requirements doc for it to be obvious that without the serial
number, we have a problem.
I think we do need a document that specifies what remediation mechanisms
are required. I
saw no reference to revocation in the doc. Some list members have
speculated that CT is
a reputation mechanism, and a recent response from you supported that
notion. A reputation
mechanism need not make use of revocation as per X.509 mechanisms. For
example, one might
have an auditor distribute a list of "bad" certs to clients, where the
public key was the
means of identifying the bad cert. I agree that one remediation
mechanism calls for the
issuing CA to put a detected, bad cert onto a CRL. But, that presumes
that the mis-issuance
was an error or the result of an attack. Since there is no attack model
for CT, I don't
know if that is the only sort of mis-issuance event it is supposed to
counter.
...
"Compliant" with what set of specs? I noted an aspect of a design
for a CA-focused
HSM that, for several years, was used by VeriSign to issue every
cert. It is a powerful
feature for high assurance cert issuance. It is also incompatible
with the precert design.
The precert design seems to preclude use of some approaches to
serial number management
that may reduce CA secruity. Thus it appears to be a tradeoff, one
that this WG has not
discussed. Please describe what you mean by a "complaint" CA.
I do not believe that the use of an HSM in any way constrains a CA's
ability to deal with serial numbers as needed. The issue of compliance
is a red herring.
You introduced the term "complaint" into this issue, not me, so if it is
a red herring, it's yours!
More to the point, I identified a legitimate way for HSMs to operate, to
reduce the vulnerability
of a CA to the sort of attack that DigiNotar experienced. And, that
model of operation has been
used by large CAs in the past. Your offhand dismissal of this issue is
inappropriate. In essence
you are saying that Google has developed a rough model of how to make CT
work and CAs need to
'make changes to their operational processes, and to software and maybe
hardware, to accommodate
your model. This is an inappropriate mindset for working in the IETF.
...
Precerts are critical because otherwise server s/w has to be updated
to deliver SCTs to clients. We know that isn't going to happen
universally any time soon. I agree the I-D should mention this.
So, the designer have decided that it is appropriate to require CAs to
change their software,
rather than asking server software developers to change theirs. I
acknowledge that there are
more servers in operation than CAs, but that's not really the right
metric. The issue is how
many sources of server software are used by the vast majority of
servers. I'm guessing that
that number is small, especially compared to the number of CAs, many of
which have had to
write all or most of their provisining software. This is a critical
design decision that
ought to be articulated in the document, and agreed upon by the WG, not
just the CT design team.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
