Ben,
...
So the scope of mis-issuance is much broader than what I had imagined.
I think we may need to add two things to 6269-bis:
- normative references to CABF documents that are the basis for the
broader
set of cert issuance criteria that you note
This seems sensible. Note, though, that I would not want to constrain
mis-issue to be solely defined by CABF. Part of the point is that
anyone can monitor any aspect of issuance they want, and if they think
something is wrong, raise it to appropriate authorities...
Mis-issuance is the primary (sole?) rationale for CT, so I am not
comfortable
with the notion that mis-issuance is not well-defined.
- maybe two appendices to enumerate the criteria. this will be critical
if
if the CABF docs contain other criteria that are outside the scope of
CT,
e.g., criteria that cannot be evaluated based on what is logged.
It would certainly be interesting to know though I don't think it is
essential - an example of something CT cannot reveal is who generates
the key (obviously it is bad practice for CAs to do this for their
customers - I don't know if BRs or EV ban the practice though - in any
case, CT would not tell you who did it).
I'm puzzled; how would CT allow a Monitor to determine who generated the
key pair used in a cert that was logged? I don't understand your example
here.
As far as I know there are no standards in this area. Chrome contains
a blacklist of certificate hashes (from memory, its been a while since
I looked at this) - I don't know what other browsers do.
Well, if we can't say how this is done, preferably based on some standard,
then we can't make an argument that, after being being detected by CT, that
there is a fix. If so, then the security considerations section will have to
discuss this residual issue.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
