Determine if optional date fields should be validated

[jdaigneau5]

Summary

Currently, optional date fields such as dateAssigned and timeline dates can have values that are future dates. These fields describe events that have already happened and should be past dates. However, We don't validate every optional field. We need to determine if these fields should be validated and how.

Proposed Actions

• Create middleware to reject containers with future dates (like datePublic)
• Determine that Cve-Services should not validate these fields

Note
This is related to a previous AWG discussion about validated optional fields or not

[zmanion]

I accidentally submitted a future datePublic for CVE-2023-6265, noticed and fixed it. I suggest that datePublic is both useful to consumers and useful in logic to reduce errors, for example, not accepting a submission with a future datePublic might defend against a premature public disclosure.

[jdaigneau5]

I accidentally submitted a future datePublic for CVE-2023-6265, noticed and fixed it. I suggest that datePublic is both useful to consumers and useful in logic to reduce errors, for example, not accepting a submission with a future datePublic might defend against a premature public disclosure.

We currently have a change addressing datePublic specifically on Test that prevents any future datePublic values. Other optional fields (time related or otherwise) might need more discussion.