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 <[email protected]
<mailto:[email protected]>> wrote:
On 16 November 2016 at 02:00, Eran Messeri <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> wrote:
>>
>> On 4 November 2016 at 14:07, Peter Bowen <[email protected]
<mailto:[email protected]>> wrote:
>> > On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie <[email protected]
<mailto:[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] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/trans
<https://www.ietf.org/mailman/listinfo/trans>
>
>
_______________________________________________
Trans mailing list
[email protected]
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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
