Re: [Trans] Relaxing section 5.1

On 17/11/16 12:21, Eran Messeri wrote:
> FYI this is the change to the draft:
> https://github.com/google/certificate-transparency-rfcs/commit/bf6603e10affbee97b07e33265494efbd07c833f

FYI, I did a couple of other tweaks, for consistency with this change.

https://github.com/google/certificate-transparency-rfcs/commit/d5087815f84510f90d0d0649a5d9f0fb402cc6af

> In addition to the change from MUST to SHOULD, I've added an example as
> to why the a log may chose to reject valid submissions.
>
> Eran
>
> On Wed, Nov 16, 2016 at 8:26 PM, Ben Laurie <benl@google.com
> <mailto:benl@google.com>> wrote:
>
>     On 16 November 2016 at 02:00, Eran Messeri <eranm@google.com
>     <mailto:eranm@google.com>> wrote:
>     > 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.
>
>     This seems like a reasonable plan (mildly surprised such a change can
>     be made without WGLC, tho!).
>
>     >
>     > On Sat, Nov 5, 2016 at 12:42 AM, Ben Laurie <benl@google.com
>     <mailto:benl@google.com>> wrote:
>     >>
>     >> On 4 November 2016 at 14:07, Peter Bowen <pzbowen@gmail.com
>     <mailto:pzbowen@gmail.com>> wrote:
>     >> > On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie <benl@google.com
>     <mailto:benl@google.com>> 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
>     >> Trans@ietf.org <mailto:Trans@ietf.org>
>     >> https://www.ietf.org/mailman/listinfo/trans
>     <https://www.ietf.org/mailman/listinfo/trans>
>     >
>     >
>
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.