text leaves open the possibility that a submitter might not verify the returned SCT

[david@…]

From ​https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-10#section-3:

The submitter SHOULD validate the returned SCT as
described in Section 9.2 if they understand its format and they
intend to use it directly in a TLS handshake or to construct a
certificate.

This wording begs the question of when a submitter ought NOT verify the returned SCT.

[rob.stradling@…]

I can't think of any case where a submitter MUST NOT or SHOULD NOT verify a returned SCT.

If we don't have anything to say, why attempt to say it?

[eranm@…]

I agree with Rob.
Cases where a submitter may not need to verify the returned SCT is when it's submitting certificates for the purpose of making them known publicly. This is clearly covered by the current text.

David, was there a particular case in mind where the standard should specify a submitter ought NOT to verify the returned SCT?

[david@…]

Replying to eranm@…:

I agree with Rob.
Cases where a submitter may not need to verify the returned SCT is when it's submitting certificates for the purpose of making them known publicly. This is clearly covered by the current text.

Sorry, I must have missed the discussion of that case. Could you point me to the text that talks about that case?

David, was there a particular case in mind where the standard should specify a submitter ought NOT to verify the returned SCT?

No, I think verification is great. I just think that this "SHOULD" should be accompanied by an explanation of the consequences of not performing the verification. That way implementors will be able to make an informed decision whether or not to verify an SCT in a particular case. Or, if there's no case in which verification should be skipped, then the "SHOULD" should be a "MUST".

[benl@…]

Addressed in ​https://github.com/google/certificate-transparency-rfcs/commit/ad41426d868446f73f5da6e62c08f21326f34476.