Re: [Trans] updated definition and attack analysis text

[Stephen Kent <[e-mail]>]

Santosh,
>
> 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."
>
I'll add a version of your text to the discussion of Monitor operation.
>
>
>      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, for the most part. Ben was the one who suggested enforcing key 
size constraints, and,
implicitly algs. Ciphersuites are a TLS internal issue, so the best we 
can do is to enforce
constraints on the algs used for cert signing, and the alg in the 
subjectPublicKeyInfo field.

> 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.
>
I have already made that change, based on one of Rick's comments.

Steve