Re: [Trans] draft-ietf-trans-rfc6962-bis-28: "no security implications"

[Ryan Sleevi <[e-mail]>]

None here. I support this change :)

On Fri, Apr 20, 2018 at 5:07 PM, Rob Stradling <[e-mail]> wrote:

> I think this is a good change.  I've posted a PR here:
> https://github.com/google/certificate-transparency-rfcs/pull/296
>
> Anyone have any objections?
>
>
> On 20/03/18 22:12, Andrew Ayer wrote:
>
>> draft-ietf-trans-rfc6962-bis-28 added the following text to
>> section 4.2:
>>
>> "While there are no security implications to a log accepting
>> a submission that does not chain to one of its accepted trust
>> anchors..."
>>
>> This isn't true.  The certificate chain enables the logged certificate
>> to be attributed to a known trust anchor.  This is security-sensitive,
>> as without the chain, monitors and trust store operators can't respond
>> to a misissued certificate because they don't know which trust anchor
>> should be sanctioned/distrusted for misissuing the certificate.[1]
>>
>> Therefore, this text should be removed.
>>
>> It might also be a good idea, to avoid any future confusion about this
>> requirement, to add "to ensure that logged certificates are attributable
>> to a known trust anchor" to the sentence at the beginning of 4.2 that
>> explains why the requirement exists.
>>
>> Regards,
>> Andrew
>>
>>
>> [1] In the general case, a monitor could probably construct the chain
>> using its own store of intermediate certificates.  But this fails if
>> the intermediate isn't known, which might happen in the adversarial
>> case where an intermediate certificate is issued for the sole purpose
>> of evading responsibility for a misissued certificate.
>>
>> _______________________________________________
>> Trans mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trans
>>
>>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: [e-mail]
>
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>