Incompliant encoding of GeneralizedTime in OCSP Repsonse

[bb-froggy]

While X.680 and X.690 allow any number of digits behind the decimal point for a GeneralizedTime, RFC 5280, Section 4.1.2.5.2 says that "GeneralizedTime values MUST NOT include fractional seconds" for X.509 certificates and CRLs. This also applies to OCSP responses as per RFC 6960, Section 4.2.2.1.

Before 879bb29, Bouncy Castle always encoded GeneralizedTime without fractional seconds; after the change, it always uses up to 7 digits, because of the format string @"yyyyMMddHHmmss.FFFFFFFK", see https://github.com/bcgit/bc-csharp/blob/master/crypto/src/asn1/Asn1GeneralizedTime.cs#L270.

When encoding an OCSP Response, if you pass in values with fractions of a second, it will incorrectly also encode the fractions of seconds. This happens in at least four places of a usual OCSP Response:

• thisUpdate (https://github.com/bcgit/bc-csharp/blob/master/crypto/src/asn1/ocsp/SingleResponse.cs)
• nextUpdate (dto.)
• producedAt (https://github.com/bcgit/bc-csharp/blob/master/crypto/src/asn1/ocsp/ResponseData.cs)
• revocationTime (https://github.com/bcgit/bc-csharp/blob/master/crypto/src/asn1/ocsp/RevokedInfo.cs)

As a workaround, the caller may remove the fractions of seconds, for example by calling a method like this:

        public static DateTime RemoveSubSecondsFromDateTime(DateTime dateTimeWithFractionOfSeconds)
            => dateTimeWithFractionOfSeconds.AddTicks(-(dateTimeWithFractionOfSeconds.Ticks % TimeSpan.TicksPerSecond));

Otherwise, the generated OCSP Response is incompliant and some clients reject it.

I suggest we search for all uses of GeneralizedTime in CRLs, X.509 certificates, and OCSP messages and remove the fraction of seconds with a call like the one above.

[peterdettman]

I've now (finally) reviewed all uses of GeneralizedTime and auto-adjusted the precision when constructed from a DateTime, for X.509 and related specs. This includes the mentioned OCSP fields and most other usages, except a couple in CMP and TSP.

Note that we do not enforce this for parsed values, and we also do not auto-adjust existing instances of Asn1GeneralizedTime provided during construction.