Ben,
On 1 July 2014 18:34, Stephen Kent <[email protected]> wrote:
Ben,
...
As you point out, the log can relax validation rules, which deals with
this problem (and we do, indeed, do that in our implementation).
My comments noted that relaxing rules in an unspecified fashion creates
potential
problems for those submitting pre-certs. The specific changes needed to
enable
acceptance oif pre-certs need to be spelled out.
Hmm. What we do is check the signatures validate all the way up the
chain. That's it. I'm not sure we need anything tighter than that, so
I guess we could specify that?
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.
CAs that randomly generate serial numbers during issuance can't
pre-generate
serial numbers to be used in the TBScertificate, then subsequently in the
final certificate. Is the serial number *that* important that it MUST be
included in the SCT? The issuer for the TBScertificate does not match
the
value of the certificate that signed it, so what's the point of the
serial
number? The CN, SAN, signing algorithms and keys are the most critical
components. Can we limit the SCT to these values?
Serial numbers are used for revocation, so we need to know what they are.
I understand the desire to have the serial number be submitted as part
of the pre-cert, but the problem raised by Doug is a valid one that
cannot be ignored.
My response is that, yes, the serial number is *that* important that
is MUST be included in the SCT.
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 burden on fixing it is not on Doug; it is on the authors of the doc!
Our position is that compliant CAs _can_ use Precertificate Signing
Certificates - though possibly not with the exact toolchain they use
to issue certificates. If someone wants to propose a mechanism that is
compatible with whatever restrictions their s/w imposes, we'd be happy
to consider it.
"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.
Ben, it's not reasonable to tell CAs that their extant serial number
management
mechanism has to change to accommodate the CT design. It is the
responsibility
of the CT designers to figure out how to accommodate valid CA operation
models.
I don't agree. If things have to change in order to achieve the agreed
goals, then they have to change. It is not our obligation to preserve
the world in its current perfection.
Agreed goals? As I noted, this WG does not have a agreed-upon set of
requirements.
We have an experimental RFC (that does not appear to have been carefully
reviewed
prior to publication, not unreasonable for an experimental RFC, but ...)
as a starting
point. The RFC identifies 3 different ways to convey SCTs. One of these
appears to
be problematic. So, maybe it's time to discuss why there are three ways
to deliver
SCTs, and why the precert method is critical.
The serial number is required to fulfil the purpose of CT. If you want
to not have serial numbers in the log, then we must also change the
revocation mechanisms.
I don't recall the doc mentioning revocation as a remediation mechanism.
On this
list someone suggested that CT is a reputation mechanism, and one might
infer that
the primary remediation mechanism is shaming CAs into submission. If we
had an architecture
doc, not just a description of a set of mechanisms, we would not have to
guess what
aspects of CT are critical and agreed upon by the WG (not just the
document authors).
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
