On Tue, Mar 7, 2017 at 7:13 PM, Ryan Sleevi <[email protected]> wrote: > > On Mon, Mar 6, 2017 at 1:06 AM, Peter Bowen <[email protected]> wrote: >> >> 8) The only way to get the content of a full certificate is to have a >> full certificate. >> >> Rationale: An alternative option is to have some sort of escrow key >> that can "unlock" a precertificate. This quickly turns into 'where do >> we keep the escrow key?' and 'who gets to access the escrow key?'. If >> there is no such thing, then these questions don't exist. > > > Can you elaborate on how you derived this principle? > > I think Rob captured well, which is there's a tension here - particularly in > the case when the domain holder signals that the CA misissued - as to how to > assess the impact and/or take corrective measure. There's a blurry line here > between what's technically required versus what is addressed by policy > external to the technology. So I think it'd be useful to understand how this > one was derived.
I think I might have phrased it poorly. It was not meant to be a policy principal, rather a technical one. What I was trying to say is that I don't think having an encrypted blob in the precertificate (i.e. publicly escrowed) that has unredacted names is a good path. I am not intending to rule out a policy that says the holder of the full certificate (i.e. the CA) must provide it to X upon Y. My focus was on the "reversibility" of the precertificate in cases where the precertificate does not contain all the data in the final certificate. Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
