Mikolaj Habryn wrote:
> Should I take it upon myself to raise this in bugzilla?
Yes. File a bug in bugzilla.mozilla.org. It may get resolved differently
than you hope, but that is the right way to push this to resolution.
> I'm not entirely
> clear on what the right solution is or even what constraints to
> describe; crypto.signText at some point calls a very generic
> CERT_VerifyCertificate, which will fail under the described conditions
> (no chain back to a root). I presume a good many other certificate
> operations take the same path, some of which presumably mandate the
> current behaviour.
CERT_VerifyCertificate is a function that is intended for use by the
application when it is acting as a "relying party", that is, when it is
using a certificate from someone else, a certificate for which it does
not have the corresponding private key, and it needs to determine the
validity of that cert prior to use, such as when verifying a signature.
crypto.signtext is not such a case. It is not acting as a "relying party".
It is performing an act (signing) that presumably will preceed some other
party relying on the certificates used to verify that signature.
(I wonder if there is a term of art for such parties, those who initiate
actions that cause others to become relying parties. For the present,
I will merely call them "signers".) While using crypto.signtext, the
application is acting as a "signer", not a relying party.
Signers need certs for which the application possesses (or has access to)
the user's private key. In NSS nomenclature, such certs are called
"user" certs. Signers need access to user certs.
Historically CERT_VerifyCert{ificate} is for use by relying parties, not
by signers. Signers need to find "user" certs. NSS has a separate set
of functions that exist to find "user" certs (separate from the set of
functions to Validate certs as a relying party). These other functions
do not, as a rule, require that the user cert have a chain that verifiably
was issued by a locally trusted root. Verifying that the chain leads to
a locally trusted root is a function for a relying party, not for a signer.
I think the "bug" here simply boils down to crypto.signtext using a
function that is for relying parties, not signers, for selecting a cert
to use for the signing act. That's probably not a big problem to fix.
> Which identities should crypto.signText be able to use?
> (a) Those for which a CA certificate has been loaded but not trusted?
> (b) Any client certificate, regardless of whether or not the signing CA
> is known?
> (c) Something more exotic, such as (a) above except where the call to
> crypto.signText supplies an unknown CA's DN in the ancillary arguments,
> in which case any certificates signed by that particular CA are also (or
> perhaps exclusively) permitted?
(d) A local "user" cert that is not obviously unsuitable on its face (e.g.
not expired, not bearing extended key usage extension that prohibits use
for signing, etc.)
>>Meanwhile what you should be able to do is to mark the CA only as
>>trusted for email which limits the risks.
>
> Thanks for confirming that.
Odd that crypto.signtext should check for an email cert when it is not
performing email signing or encryption.
--
Nelson B
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
