On 7 July 2014 16:57, Doug Beattie <[email protected]> wrote: > > > > 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.
As I've said, any rules can be relaxed - inclusion in the log says nothing about the validity of certificates. Clearly there are some rules that MUST be relaxed, and I guess we can attempt to enumerate them. > 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. I don't think we can make that impossible - for example, what is the definitive set of CAs that all logs should accept? > >> >>> >>> >>> >>> _______________________________________________ >>> 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
