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 Sectigo Limited _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
