Re: [Trans] updated definition and attack analysis text

[Stephen Kent <[e-mail]>]

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