Re: [Trans] updated definition and attack analysis text

[Santosh Chokhani <[e-mail]>]

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:[e-mail]] On Behalf Of Stephen Kent
Sent: Friday, October 03, 2014 3:31 PM
To: [e-mail]
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