On 2014-09-09 21:43, Stephen Kent wrote:
Brad,
Whatever is logged ought to be as close as is possible to the actual
certificate and ought to include all meaningful information in the
certificate other than a preimage-resistant hash.
Absent a clear description of scope, i.e., what problem is being solved,
the approach
of "include everything" is understandable. But that doesn't make it the
best approach.
Detecting problematic issuance isn't confined just to organizational
authority. Looking at the recent history of bugs in this area,
observing a flurry of issuance of certificates of the form
"www.legit.com\0www.evil.com", or certificates with large "tumors" in
rarely used or obsolete extensions might have been cause to
investigate deeper and additionally could've provided evidence of
stealthier prior exploitation of such bugs.
Again, if the I-D stated what problem is being solved, and the examples
you cite are
part of that description, then covering everything in a cert makes more
sense, but ...
We can't predict in advance what such problems will be, so the default
stance should be that everything is logged, and the onus fall on those
who want to exclude content to justify that action.
The question of logging everything is not that clear even today. As
there is currently drafted how to exclude private domain names in the
PreCertificates being logged. I see possibility for either:
- Log everything by default, risking to add one item after another that
can optionally not be logged (=can become complex)
- Define what is to be logged, risking adding new things continuously
(=can become complex)
In any way, the PreCertificate will most likely (almost)never have
exactly the same information as the real certificate.
I see your point, and if the I-D clearly stated the sort of very broad
goals that you
note above, I think your argument would be a good one. We already have
one example of
folks wanting to exclude info, in the case of redacted certs. I'm not
yet convinced
that the proposed mechanism is safe, but we'll see.
With regard particularly to serial numbers it's clear they are
necessary as input to revocation mechanisms.
yes, and my suggested alternative mechanism preserves logging of serial
numbers, as
a separate step for CAs (not for Subjects or others who have a cert for
which an SCT
is to be created as a post-issuance artifact.) But, I think the I-D
needs to be clear
about the threat model so that we can see why revocation is part of a
remediation plan
in some circumstances. The current text is way too vague on this topic,
as I noted in
my review prior to the Toronto meeting.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
