On 09/06/12 06:03, Wan-Teh Chang wrote:
> Please fix the bug in the "old" certificate verification library. Thanks.
> Are you going to use the approach outlined by Nelson in bug 479508 and
> bug 482153?
I'm afraid I have nowhere near enough knowledge of NSS internals to turn
Nelson's "disgusting hack"  into something that the NSS team would,
under normal circumstances, "contemplate committing" .
I've just tested Nelson's 2 patches ( and ) against
mozilla-inbound, and they appear to fix the problem. IMHO, a
"disgusting hack" fix is much better than a non-disgusting,
significantly delayed fix.
So, how would Mozilla and the NSS Team feel about committing Nelson's 2
P.S. An alternative idea, for which I am willing to write a patch (if
you think this would be preferable to Nelson's "disgusting hack"):
- Define a certHashesToAvoidUsing array in
nssCertificateArray_FindBestCertificate(). Populate this array with the
hashes of all of the UTN->AddTrust and AddTrust->UTN cross-certificates.
Make the code consult this list: if a match is found, do not consider
this cert to be the best match.
P.P.S. 2 other ideas which didn't appear to work...
1. I tried adding the affected UTN<-->AddTrust cross-certificates as
distrusted built-ins, but this didn't help. Presumably "distrust" is
only evaluated after the "best" certificate chain has been chosen,
rather than during the process of chain selection.
2. I tried removing one of the affected UTN root-certificates and then
adding the relevant AddTrust->UTN cross-certificate as a built-in. This
didn't work either, presumably because the UTN root-certificate was for
some reason still listed as a Software Security Device.
Senior Research & Development Scientist
COMODO - Creating Trust Online