Re: [Trans] AD Review of draft-ietf-trans-rfc6962-bis-30

[Rob Stradling <[e-mail]>]

EKR,

We just published -31, which we believe addresses all of your A-D review 
comments.  Please let us know if there are any other issues to address 
before 6962-bis can be sent to the IESG.

Thanks.

On 28/12/2018 10:33, Rob Stradling wrote:
> On 26/12/2018 19:31, Paul Wouters wrote:
>> On Wed, 26 Dec 2018, Eric Rescorla wrote:
> <snip>
>>>        >       > >      In addition to normal validation of the server
>>> certificate and its
>>>        >       > >      chain, CT-using TLS clients MUST validate each
>>> received SCT for which
>>>        >       > >      they have the corresponding log's parameters.
>>> To validate an SCT, a
>>>        >       > >      TLS client computes the signature input by
>>> constructing a "TransItem"
>>>        >       > >      of type "x509_entry_v2" or "precert_entry_v2",
>>> depending on the SCT's
>>>        >       >
>>>        >       > How do I proceed if I have an invalid SCT but by
>>> policy I would accept
>>>        >       > the certificate if the SCT had been omitted.
>>>        >
>>>        >       The section quoted tells you what to do with invalid
>>> SCT's, namely fail the validation.
>>>        >
>>>        > This text does not tell you to fail validation of the
>>> certificate; it tells you you MUST validate all the SCTs and then
>>> doesn't tell you how to behave if one does not validate.
>>>
>>>        I believe the actions of what to do on validation failure are a
>>> local
>>>        policy. It could be a total rejection, a popup etc. While
>>> 6962bis gives
>>>        guidance for CT-using TLS clients, it is not a client specification
>>>        document. See also: https://trac.ietf.org/trac/trans/ticket/15
>>>
>>>
>>> But there is a MUST here for clients, and so again, the boundaries of
>>> that MUST need to be clear.
>>
>> The MUST tells you to validate, not to tell you exactly what to do when
>> validation fails. So it tells you that you cannot skip validating the
>> 3rd SCT even if you only needed two according to your client policy. So
>> I still do not understand why you think this case is a problem.
>>
>>>        >       I suspec your real question is if that is the right
>>> thing to do when
>>>        >       SCT's were not mandatory as policy for the CT-using
>>> clients?
>>>        >
>>>        > No, that's not my question. Consider the case where my policy
>>> is that there must be 2 valid SCTs and the server supplies 3 but only
>>> 2 validate. I'm required to validate all of them, but I could
>>>        conform with
>>>        > this text by validating all three, logging the failure, and
>>> moving on.
>>>
>>>        That behaviour is up to the client implementation and/or local
>>> policy.
>>>
>>>
>>> Great. Then the text should say that.
>>
>>> I'm not asking for a complete client specification. What I am asking
>>> is that every normative requirement in this specification be
>>> unambiguous, and I do not believe that this one is.
>>
>> I think it does, but I guess it won't harm to make it more explicit.
>> I'll leave that up to the authors.
> 
> This is already covered by section 8.1.6 "Evaluating compliance", but...OK.
> 
> Proposed text:
> https://github.com/google/certificate-transparency-rfcs/pull/306
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Email: [e-mail]
Bradford, UK
Office: [phone]
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.