Steve, How about the following
"The entity (monitor, subject, or another entity) that is examining the logs for certificate of interest for a subject (i.e., domain) has or obtains a list valid certificates from the subject in a secure manner. The examining party or the subject must not rely on the authorized CA or RA database for this information or use certificate discovery protocols; this information must be developed by the subject based on the certificates it has obtained and installed. If the authorized CA or RA database is used to reconcile with the certificates in the log, the mechanism does not detect mis-issuance due to malfeasance on the part of the authorized CA or the RA or due to compromise of the authorized CA or the RA. If the authorized CA or RA database is used, it does detect mis-issuance by unauthorized CA. The examining party must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms may also result in mis-issued certificates being added to the list." From: Trans [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Friday, October 03, 2014 3:31 PM To: [email protected] Subject: Re: [Trans] updated definition and attack analysis text 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
