Ben,
...
I think its pretty clear what the purpose of CT is - to make it
possible to detect mis-issuance of certificates - i.e. that
certificates conform to all the requirements for issuance. And its
also clear that to do this, you need to be able to see the contents of
the certificate. This is the threat model. Or, if you really want it
phrased as a threat, the threat is that some CA might issue a
certificate that does not conform to the requirements for issuance
(which, btw, vary over time) and the mitigation is a public,
append-only, verifiable log of the contents of all issued
certificates.
The I-D clearly states this already, I think, but if you don't like
the text, perhaps you can propose something you'd like better?
Here's some suggested text that matches my model for a threat model
description:
...
However, when you suggest that inclusion of some particular thing is
problematic, then we can, of course, refer to potential problems CT
might reveal and available remedies as an illustration of why that
thing is needed.
I don't know what this last, rather long sentence means. Please elaborate.
What I meant was that mentioning a problem in order to explain why
some field is needed does not mean that we then have to enumerate all
problems, find a problem that justifies every field, etc.
Thanks for the clarification. I disagree. If one lists every field
to be covered by an SCT, and notes why the field needs to be covered,
then the coverage is clearly justified. Saying that we'll cover every field
because there might be a need to do so, even though we can't articulate
it, can lead to unnecessary complexity. For example, right now TCPINC
WG is performing this exercise for the TCP header, to justify which fields
needs to be integrity-protected. I agree that an X.509 cert is a much
bigger, more complex data structure, but the principle is the same.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
