On Thu, Feb 10, 2022 at 04:20:40PM +0100, Claudio Jeker wrote:
> On Thu, Feb 10, 2022 at 04:09:40PM +0100, Theo Buehler wrote:
> > On Thu, Feb 10, 2022 at 03:02:15PM +0100, Claudio Jeker wrote:
> > > This adds the needed bits to print CRL files.
> > > Using ASN1_INTEGER_get() is probably bad at least I think there is the
> > > possibility the serial number wont fit in the long. I hope tb@ has a
> > > better solution :)
> >
> > According to RFC 5280, issuer + serialNumber must identify the cert
> > uniquely so applications should be able to handle serialNumbers of
> > at least 20 octets. The upper bound is 64 octets.
> >
> > I don't have a particularly elegant solution. The options offered
> > by libcrypto that come to mind are to convert to a BIGNUM and use
> > BN_print_fp() or to use a BIO and i2a_ASN1_INTEGER. Neither is
> > particularly appealing.
>
> I would suggest we extract the code from mft.c to handle the manifest
> number. The only difference is the limit of 20 vs 64 it seems.
> Then we have a common function for serial numbers.
Even better. I forgot we had that. It's fine to restrict to 20 for both.
Certificate users MUST be able to handle
serialNumber values up to 20 octets in length. Conforming CAs MUST
NOT use serialNumber values longer than 20 octets.
> > > I created x509_get_time() to streamline the ASN1_TIME to time_t
> > > conversion and replaced a bunch of calls. mft.c uses ASN1_GENERALIZEDTIME
> > > and can not be converted.
> >
> > We already check that the ASN.1 type is ASN1_GENERALIZEDTIME before
> > calling mft_parse_time(). I'm not sure how much this being slightly
> > stricter buys us.
>
> Can we typecast a ASN1_GENERALIZEDTIME into a ASN1_TIME?
Yes. These are all just glorified ASN1_STRINGs, see
/usr/inclued/openssl/openssl_typ.h
