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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
