Santosh,
Steve,
Thanks.
My primary concern with the analysis is that it does not discuss the
practicality and resources and data required for the monitoring
activity. It is quite possible that monitoring will not be done at
all or will miss things or will be ineffective leaving the benefit of
CT to largely as a deterrent as opposed to detection mechanism.
Threat analysis may wish to point that out with significant emphasis
since 6962 does not seem to emphasize this enough. I see CAs offering
to perform monitoring service, which will not detect problems if the
authorized CA or RA are compromised or have gone rogue. In summary,
the last paragraph of the analysis may wish to point out the monitors
may require subjects to use secure means to provide a list of valid
certificates from time to time and for monitor to check the logs for
mis-issuance against this list. 6962 does not address the critical
aspect of monitoring from the perspective of checking that the
certificates are legitimate.
I'm happy to specific receive text to add to the analysis. I'll be
updating it next week
to reflect the revised syntax checking anyway. Also, I have completed
an initial cut at
the EV cert syntax rules and pkan to issue a complete Appendix A version
next week as well.
I agree that a CA that operates a log for itself, or a Monitor for its
clients seems
questionable. When I think about Monitor services I look at what is
available today for
address space monitoring. Companies monitor BGP advertisements, from
open and proprietary
sources, looking for advertisements of prefixes that belong to client.
If an advertised prefix
does not have the origin AS of the client, it's suspicious. The client
is informed and can take
action, e.g., contacting the AS that is advertising itself as the origin
of the client's prefix.
This works reasonable well, but it is a for profit activity, i.e.,
people pay to have their
prefixes monitored. If the designers of CT envision this as a likely
deployment scenario for
CT, it ought to be mentioned.
While just about everyone is against checking the certification path
and certificate, but if the goal is to secure Web PKI, to improve user
experience or at least protect less informed users from making bad
choices when a browser barfs, I would think checking certificate,
certification path, and even cipher suites including proper range for
RSA public exponent are good things.
I agree. Since I revised my proposal, so that even certs that fail
syntactic validation are
logged, maybe we can revisit the path validation issue. One could
imagine adding an error
code to an SCT that noted when the syntax is OK, but path validation
fails, and why.
On specifics of your analysis, on Note 2, I would think the CA may
wish to get the whole certificate to verify that the certificate was
issued by it by verifying the signature using its own public keys.
Good point. The log entry contains the cert, so it makes sense to
provide that to the CA
what requesting that the cert be revoked. I'll make that change.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
