Time_Stamp == EKU_Time_Stamp // 597-601
Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP.What is the difference between these two? Looking at the wording, they seem identical - EKU stands for EXT_KEY_USAGE...
One is the bit set in the Netscape Certificate extension and the other is the oid in the EKU extension.
The point is that the Netscape Cert type extension can set any bit in our certType.
Right if you don't have a NS cert type or EKU extension, then you likely have a primitive cert, which requires a whole lot more futzing to tell if it's a CA cert or not (basically the extra futzing is "did someone tell us this is a CA cert in the certdb", which in general happens with root certs primarily).It seems the conditions under which a cert is given EXT_KEY_USAGE_STATUS_RESPONDER are wider than those for the other types...I'm not sure what you mean by this.I mean that (for certs with no NS extension and no EKU) the cert is given type EXT_KEY_USAGE_STATUS_RESPONDER if CERT_IsCACert() returns true. This is a more expansive check than merely seeing if basicConstraint.isCA is true - which is what is checked for the other cert types. I am talking about lines 610-618.
It depends on how critical it is to parsing BR certs. Is it important to know a CA is only treated as a CA if it has basic constraints (barring the database override). I was offering that it might be possible to remove it, but I don't have a pressing need to remove it.;).two. It's been several decades since we have the general constraints and the NS Cert extension is basically redundant in face of that, so I think it would be good to look at deprecating the support for parsing NS Cert extensions altogether. (It may even be safer to do this than to drop support for certs with neither extension).Feel free to file a bug :-)
Gerv
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
