On 15/08/13 19:01, Robert Relyea wrote: > That's an instrumentation issue. It was true back in 1995/6 when the > code was added I don't know how true it is today. My guess is the > biggest compatibility issue is self-issued certs, not CA issued certs... > but then again most of those are self-signed...
Are we currently gathering cert data using Telemetry? Perhaps this could be added. >> 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... >> 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. > 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
