#126: text leaves open the possibility that a submitter might not verify the returned SCT
Comment (by [email protected]): Replying to [comment:2 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". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- [email protected] | [email protected] Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/126#comment:3> trans <http://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
