From: Ben Laurie <[email protected]> Date: Monday, July 7, 2014 at 10:14 AM To: Carl Wallace <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
> <snip> 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 was not suggesting that the log be relied upon to do the check. The point was the log is in a position to observe when things have gone wrong across a broad range of certs and highlighting these instances as a courtesy may be worth doing. Monitoring for names is probably sufficient to capture name constraints violations of interest to a given monitor but drawing attention to violations may cast some doubt on a CA's operations in general.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
