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.
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
