Subject: [Trans] redacted names and my proposal

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Sep 2014 14:37:06 -0400

Rob,

My intent, perhaps not well articulated, was that the SCT* submission 
would use
the same name redaction mechanism you proposed, if they prove to be viable.

The step 4 submission would include that same data, the serial number, 
and the
previously-issued SCT*. This would enable a log (doing more work) to 
ensure that
the SCT it issues is consistent between the two submissions. It also 
ensures that
the serial number is available for revocation when needed (which arises 
in only
some of the attack scenarios).

Thus, whatever name redaction mechanism the WG ultimately deems suitable 
should
work in my suggested two-phase protocol.

As Ben noted, there is a residual vulnerability with my proposal since 
the SCT*
is not tied to the serial number. But, in the context of the attack 
analysis I just
submitted,  I'm not sure how serious this vulnerability is, relative to 
the other
ones that I identified in the current CT design. We should discuss that 
later,
once we have agreement on an attack analysis.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Fri, 12 Sep 2014 11:03:23 +0100

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).

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.

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.

And if we can't avoid that requirement, I don't see how a two-phase 
approach would offer any benefit.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Sep 2014 14:52:26 -0400

Rob,
> 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.
> least know its serial number so that it is revocable.
see my reply above.
> 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