Option number 2 (The message is 'valid' and can be signed now, but the signature can be used only after the "Not-Before" date.).
"Valid" is perhaps the tricky word here, since in terms of whether a specific Sign-in With Ethereum (SIWE) can be used as authentication, all messages are "invalid" until signed. If an end user is not permitted to sign "an invalid message", then no draft SIWE messages could be signed. So, "valid" to be used for authentication and "valid" for the user to sign have to be two separate things.
If the Sign-in With Ethereum (SIWE) specification only allowed end users to create messages with
not-before dates in the past, then the parameter would be useless because
issued-at also exists in the specification and is required. If both
not-before dates were required to be in the past, then there's no real point in the duplication.
Therefore, a SIWE message is "valid" to be signed if the structure is appropriate (i.e. if
not-before is present, it's an ISO-formatted date). Similar to a "postdated" paper check: if a paper check has a date on it in the future, it's still "a check" (it is a valid message), but it's only actionable if the owner has signed it. Similarly, the SIWE message is a valid message if structured properly, but not actionable until paired with a signature from the owning address.
What is likely ambiguous is how each site will handle valid, signed SIWE messages that do have a
not-before date in the future. If a site knows their own login process never "postdates" a SIWE message, they may view a client connection that presents a SIWE with a
not-before date in the future as an attacker and silently flag that client connection as malicious (e.g. take strikes toward an IP block). While another site that does provide a mechanism for users to take an action in the future (e.g. start of a rental period, or as authorization for a third-party to take an action on their behalf but it must be within a certain time window) might parse it and display it as a formatted notification to the end-user, for the context it means on their site ("Alice, your rental period hasn't started yet; come back at "). I think that's fine for sites to handle it differently like this, and it can be a user education point that users should be asking questions of the apps they interact with to know how that specific project handles this field.