My proposed compromise at the trans workgroup meeting yesterday was to change the MUST in the following paragraph to a SHOULD: "Logs MUST accept certificates and precertificates that are fully valid according to RFC 5280 verification rules and are submitted with such a chain."
I believe that this change allows creating logs that can reject valid submissions under some circumstances while complying with 6962-bis. And we wouldn't have to go through WGLC again for such a change. On Sat, Nov 5, 2016 at 12:42 AM, Ben Laurie <[email protected]> wrote: > On 4 November 2016 at 14:07, Peter Bowen <[email protected]> wrote: > > On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie <[email protected]> wrote: > >> > >> The bit you didn't quote does say they the log has to accept valid > >> certs, tho: "Logs MUST accept certificates and precertificates that > >> are fully valid according to RFC 5280 [RFC5280] verification rules and > >> are submitted with such a chain." > > > > Sorry about that. So the three MUSTs together are: > > > > - Logs MUST verify that each submitted certificate or precertificate > > has a valid signature chain to an accepted trust anchor, using the > > chain of intermediate CA certificates provided by the submitter. > > > > - Logs MUST reject submissions without a valid signature chain to an > > accepted trust anchor. > > > > - Logs MUST accept certificates and precertificates that are fully > > valid according to RFC 5280 verification rules and are submitted with > > such a chain. > > > > When I read these together, I read that Logs must accept _any_ > > certificate that is fully valid according to RFC 5280 verification > > rules and chains to any root the log trusts and logs must _only_ log > > such certificates (and no others). > > > > If this is accurate, we need to account for all types of certificates > > being logged, as a log cannot choose to reject certificates for usages > > other than server authentication and the log cannot reject > > certificates that have personal information (e.g. an server > > authentication certificate that states which human requested the > > certificate in the subject). > > > > This seems like a very strong assertion of policy rather than a > > technical discussion of how the CT protocol works. I would again ask > > the WG to reconsider the requirement levels specified in this section. > > FWIW, I tend to agree. I would also note that operationally, we have > already discussed options for logs that are incompatible with these > requirements, for example: > > * sharded logs (e.g. by hash(cert) mod n). > > * logs that only accept short or long lifetime certificates (this > would allow the working set to be reduced in size for CAs that issue a > lot of short-lived certs). > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
