Rob,
Steve, my point is that the name redaction mechanism I proposed is,
necessarily, a one-phase protocol. The Precertificate must be logged
(hence phase 1), and the final certificate must not be required to be
logged (hence the lack of a phase 2).
Your requirements are not in conflict with my proposal. In phase 1 the
redacted name would be
input. In Phase 2, the same input as in Phase 1 would be supplied, plus
the serial number. My
initial characterization of the proposal didn't consider name redaction,
and thus described
the second phase as using the issued cert. But, I tried to clarify that
when you pointed out
that I had failed to consider redacted certs, initially.
If the final certificate is logged, then the redacted names become
public. If the final certificate is not logged, then we need to at
least know its serial number so that it is revocable.
see my reply above.
I don't think we can avoid requiring the serial number of the final
certificate to be seen by the log before the final certificate is
actually issued, because the embedded SCT(s) in the final certificate
need to prove that the log(s) have seen that serial number.
My proposal does have the serial number in the log, acquired in the
second pass. It's not clear
that an embedded SCT needs to include the serial number, absent a more
thorough description of
client and Monitor behavior. I agree that there is a residual
vulnerability, noted by Ben, if the serial number is not present. But,
there appear to be several other vulnerabilities with the
current design, based on my first cut attack analysis.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
