On Mon, Jul 7, 2014 at 10:14 AM, Ben Laurie <[email protected]> wrote: > > > > On 5 July 2014 19:34, Carl Wallace <[email protected]> wrote: > >> From: Stephen Kent <[email protected]> >> Date: Saturday, July 5, 2014 at 8:50 AM >> To: Ben Laurie <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign >> TBScertificates for CT >> >> > >> > On 1 July 2014 18:34, Stephen Kent <[email protected]> >> ><mailto:[email protected]> wrote: >> > ... >> > >> >As you point out, the log can relax validation rules, which deals with >> >this problem (and we do, indeed, do that in our implementation). >> > >> > >> > >> > My comments noted that relaxing rules in an unspecified fashion >> >creates >> >potential >> >problems for those submitting pre-certs. The specific changes needed to >> >enable >> >acceptance oif pre-certs need to be spelled out. >> > >> > >> > >> > Hmm. What we do is check the signatures validate all the way up the >> >chain. That's it. I'm not sure we need anything tighter than that, so >> >I guess we could specify that? >> > >> > >> > Ok, that's what you do, but 5280 describes a long list of >> > cert path validation rules >> > and your doc just says that these can be relaxed. It does not >> > prohibit a log from >> > performing the full set dictated by PKIX and X.509 path validation >> > procedures, nor >> > does it provide guidance of which subset SHOULD/MUST be performed. >> > Absent such guidance >> > different log operators can legitimately perform different checks, >> > resulting in chaos. >> > >> >> Seems easy enough to specify and justify the relaxed rules (signature >> checking only) for this application but is it worth supporting the >> highlighting of errors, like name constraint violations, to draw the >> attention of log monitors? An indication could probably be represented as >> a CTExtension. >> > > Seems to me that it would be better to share the rules for checking such > things (ideally as open source software) than to have people rely on third > parties to correctly flag... >
I’m not connecting the logic from the last couple of emails. We know that path validation *cannot* follow PKIX and path validation procedures because when a Pre-certificate signing certificate is used the Issuer DN, AIA and Auth Key ID will *all* not correctly point to the pre-certificate. We need to change “may” to “must” in this parenthetical note in 3.1: “(note that the log may relax standard validation rules to allow this, so long as the issued certificate will be valid),” and we need to specify exactly which rules can be relaxed. The use of pre-signing certificates is a good thing from a security perspective. It lets you off-load the external communications from you CA and you can locate this in a different security zone in your infrastructure with different security requirements. Specifying how log operators handle these chains is essential or the ability to obtain SCTs will vary from one log operator to another. > >> >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
