Gervase Markham wrote, On 2008-06-06 02:07: > Another option would be to make a (small? :-) modification to NSS to > allow us to store an expiry date which overrode the one in the > certificate.
Not small, I think. But not infeasible. PKCS#11 does define attributes for certificate objects, named CKA_START_DATE and CKA_END_DATE, which may be empty or may be an array of 8 bytes containing a string of the form YYYYMMDD. Note: date only, no time, and no time zone, so date is UTC. PKCS#11 says, of these attributes: > When present, the application is responsible to set them to values that > match the certificate’s encoded “not before” and “not after” fields (if > any). Because these attributes are nominally empty, and when present, are defined to merely match the value in the cert itself, NSS makes no use of them. But one could imagine that we make use of them, and allow the values of the CKA_END_DATE to be different from (earlier than) the notAfter date in the related certificate. The work would be in a) devising an NSS API to set them (maybe not necessary if we only do this for certs in the built-in read-only root CA certs token). b) propagating the value of these attributes, when not empty, into NSS's CERTCertificate structure, where they would be treated as if they were the actual notBefore and notAfter dates, superseding the values in the certs themselves. I imagine that there might be some confusion if people find that NSS is treating a cert as having a different expiration date than the date that actually appears in the certificate itself. Personally, I really would not want to have to answer those frequently asked questions. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
