No. That is not what I meant to say. I was trying to answer your query
about the rule regarding 2050 and signing-time.
I see (at least I hope to).
Five years ago, there was a debate about the signing-time attribute. In
PKCS#9, it only supports UTCTime. There was a debate about using the same
OID with the construct that includes a GeneralizedTime alternative. At
that time, the decision was to align with RFC 2459. X.509 was also being
updated at roughly the same time.
The situation is different:
Supporting GeneralizedTime in the signedTime attribute is not necessary
before 2050, so you don't have an alternative encoding but a new one
after 2050. It is an upgrade that doe not create backwards compatibility
problems (as far as I see).
PKCS#9 v2 had been aligned to add generalizedtime, 2?
Your spec creates an alternative encoding for dates, which require
more than a migration, you will need to code both
attributes, always.
A receiving implementation of the new attributes must be prepared to handle
the two options, i.e. UTCTIME/GT or binary, since on creation you can
use any of them. So in one way or the other, a decoder need some
conversion routine, unless you have made some prior agreement.
Or, at least I'd remove the non-binary choices from the new attribute,
i.e. use the initial proposition.