Forcing specific CA for domain
Balint Balogh
Suppose Example Ltd. runs its own local CA that issues certificates to servers
and email addresses at example.com and its subdomains. The certificate of this
CA is installed as a trusted CA certificate into every browser (Firefox) and
email client (Thunderbird) of employees.
Example Ltd. wants to make sure that only their own CA may sign certificates
claiming to belong to example.com or any of its subdomains. That is, if a user
tries to connect to any *.example.com server whose SSL/TLS certificate has not
been signed by the CA of Example Ltd., the user should see a security warning
about an invalid server certificate (likewise for email if using S/MIME).
Without this security measure, any CA that has its certificates in client
software has the power to thwart SSL/TLS security by issuing fake certificates
claiming to belong to *.example.com servers or email addresses.
Is there a way around this problem, without disabling or removing all other
certificates? Certificates signed by other, widely recognized CAs, whose
certificates are included by default in Mozilla products should still be
considered valid except for *.example.com domains.
Thanks for any help.
Balint Balogh
Nelson B
> Hello
>
> Suppose Example Ltd. runs its own local CA that issues certificates to servers
> and email addresses at example.com and its subdomains. The certificate of this
> CA is installed as a trusted CA certificate into every browser (Firefox) and
> email client (Thunderbird) of employees.
>
> Example Ltd. wants to make sure that only their own CA may sign certificates
> claiming to belong to example.com or any of its subdomains. That is, if a user
> tries to connect to any *.example.com server whose SSL/TLS certificate has not
> been signed by the CA of Example Ltd., the user should see a security warning
> about an invalid server certificate (likewise for email if using S/MIME).
In general, this cannot be done. It is possible to put "name constraints"
on CAs that are subordinate to a root CA, but not generally on root CAs.
> Without this security measure, any CA that has its certificates in client
> software has the power to thwart SSL/TLS security by issuing fake certificates
> claiming to belong to *.example.com servers or email addresses.
The user has control over which CAs he trusts. If there are CAs in the
browser's list that the user believes to be untrustworthy, then the user
can tell his browser to actively distrust them.
> Is there a way around this problem, without disabling or removing all other
> certificates? Certificates signed by other, widely recognized CAs, whose
> certificates are included by default in Mozilla products should still be
> considered valid except for *.example.com domains.
If you really don't trust any CAs except your own to be truthful to you,
then you should mark all other CAs but your own as distrusted.
> Thanks for any help.
>
> Balint Balogh
Regards
--
Nelson B
Balint Balogh
> In general, this cannot be done. It is possible to put "name constraints"
> on CAs that are subordinate to a root CA, but not generally on root CAs.
I was afraid of getting an answer like this but thanks for replying anyway. :)
> The user has control over which CAs he trusts. If there are CAs in the
> browser's list that the user believes to be untrustworthy, then the user
> can tell his browser to actively distrust them.
User control of that sort is an adequate tool if the issue is about a specific
set of CAs considered untrustworthy in general. However the problem is the
other way around: All except one CA (or set of CAs) are considered
untrustworthy but only for a very specific purpose, they are considered
trustworthy otherwise.
> If you really don't trust any CAs except your own to be truthful to you,
> then you should mark all other CAs but your own as distrusted.
This is not a practical possibility because that would render SSL/TLS secured
browsing and S/MIME secured email correspondence outside of example.com
impossible. (Assuming users are trained to reject any communication attempt
involving invalid certificates, which they should be if we are to talk about
security at all.)
It seems to me this issue is a grave security problem. Fortunately it can be
corrected from the client side alone without touching established protocols
and standards, by allowing users to set local policies about which CAs are
allowed to sign certificates matching certain criteria (e.g. those that belong
to a specific domain).
I would really like to hear others' opinion about this issue.
Regards,
Balint Balogh
Kyle Hamilton
sign things in that domain?
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
-Kyle H
Balint Balogh
Kyle Hamilton wrote:
> Maybe a TXT record or recordset with the AKIDs that it authorizes to
> sign things in that domain?
I suppose you mean TXT records in the DNS.
(Excuse me for my ignorance but what is an AKID?)
TXT records in the DNS may be a moderately useful way of restricting the set
of root certificates that the rest of the world should consider trustworthy
for communication with a certain domain. While this scheme might increase
security somewhat, it does in no way guarantee security, because it would
easily fall to DNS poisoning.
I do not see how TXT records containing any information would remove the need
for a root CA which, and only which, is explicitely authorized locally at the
client to sign certificates (or TXT records, whatever) for a specific domain.
Regards,
Balint Balogh
Bob Relyea
> Hello
>
>
>> In general, this cannot be done. It is possible to put "name constraints"
>> on CAs that are subordinate to a root CA, but not generally on root CAs.
>>
> I was afraid of getting an answer like this but thanks for replying anyway. :)
>
solve.
In the PKIX model you would create a new intermediate with the same
subject and keys as the root cert you want to trust. You would then add
constraint extenstions to the intermediate to limit what name spaces it
can use (and what policies it can issue). That allows you to extend
limitted trust to other certificate domains.
PKIX is currently planned for NSS 3.12, so won't be available in any
mozilla based products this year.
bob
Nelson B
>>> In general, this cannot be done. It is possible to put "name constraints"
>>> on CAs that are subordinate to a root CA, but not generally on root CAs.
>>>
>> I was afraid of getting an answer like this but thanks for replying anyway. :)
>>
> This is the general problem PKIX and cross certificates are supposed to
> solve.
>
> In the PKIX model you would create a new intermediate with the same
> subject and keys as the root cert you want to trust. You would then add
> constraint extenstions to the intermediate to limit what name spaces it
> can use (and what policies it can issue). That allows you to extend
> limitted trust to other certificate domains.
This is consistent with what I said. Distrust all roots CAs but your own.
Issue intermediate CA certs with name constraints that effectively replace
all the distrusted root certs.
> PKIX is currently planned for NSS 3.12, so won't be available in any
> mozilla based products this year.
He needn't wait for PKIX to do the above. PKIX is only needed if he's going
to involve policy-based chain building.
--
Nelson B
Balint Balogh
> This is consistent with what I said. Distrust all roots CAs but your own.
> Issue intermediate CA certs with name constraints that effectively replace
> all the distrusted root certs.
Now I guess I understand how this would work. This seems to be a viable
solution, but it is cumbersome and error-prone in the long run since one must
keep track of root CAs included in client products, update certifications and
root CA invalidations accordingly and roll them out to users.
A simple static policy would be a lot easier to setup, maintain and check for
correctness.
Regards,
Balint Balogh
Gervase Markham
> Without this security measure, any CA that has its certificates in client
> software has the power to thwart SSL/TLS security by issuing fake certificates
> claiming to belong to *.example.com servers or email addresses.
If you think they might do that, why might they not do it for other
domains your users use (e.g. their bank)?
Surely you either believe a CA is trustworthy to correctly issue
certificates for websites or it isn't?
Or are you concerned that a rogue employee at an otherwise honest CA
will have a particular wish to undermine your company and employees and
will cause a single bogus certificate to be issued as part of his
campaign to target you?
Gerv
Kyle Hamilton
identify what CA they use, that prevents any other CA -- even one who
ends up inadvertently issuing certificates contrary to their CPS --
from causing damage, and thus lowers the risk of any individual CA
that may be in any given browser from blundering. These lists of CAs
are huge, and protecting from 120 possible threats by denying all by
default and adding explicitly-trusted-by-server-to-identify-server CAs
to the "allowed" list one at a time... well, let's just say that it's
a lot harder to get an inside man into one specific company than it is
to get an inside man into any of the companies on the list.
(And since the list of "trusted" CAs on the client is unknown, it's
entirely possible that the Chinese Firewall exists -- a bunch of proxy
servers that are trusted for every domain in the world. If one could
signal that the only acceptable CA for the domain was not Chinese
Firewall-type, then one could know that, for example, you'd never have
to worry about the Chinese police trying to extradite you for speech
which is free in your country, but which is anathema in that country.)
...but then again, with the Chinese Firewall theory, you also get the
Brain In A Vat scenario, where you'd never be able to tell if your
input was bogus.
-Kyle H
Balint Balogh
Gervase Markham wrote:
> If you think they might do that, why might they not do it for other
> domains your users use (e.g. their bank)?
They might but I do not have direct control about that so I have to accept the
risk or try to reduce it through other means. However I have direct control
about our own certificates and client machines so I want to secure them as
much as practically possible.
> Surely you either believe a CA is trustworthy to correctly issue
> certificates for websites or it isn't?
I definitely do not consider any CA to be absolutely trustworthy to issue all
sort of certificates, but in a lot of cases where I have to deal with
certificates of parties I do not have direct contact with, trusting a
well-known CA is a good trade-off between security and ease of use since it
isn't very practical to get all certificates directly from their owners.
> Or are you concerned that a rogue employee at an otherwise honest CA
> will have a particular wish to undermine your company and employees and
> will cause a single bogus certificate to be issued as part of his
> campaign to target you?
It's not that I am particularly concerned that someone is attacking our
company this way (though others may be), rather I would like to avoid
introducing an additional and unnecessary risk by allowing CAs to interfere
with internal company communications. The particular trade-off I described
above is completely unneeded in internal communications because usually all
employes and branch offices, etc. can get our certificates directly from the
source. There is no need to introduce another party in the certification
chain, in fact any other party inevitably reduces security.
In the case of X.509 certificates as used in common SSL/TLS and S/MIME
implementations however, we are not talking about a single unnecessary third
party in our certificate chain (actually at the top of it) but a whole lot of
them. This lot does make me worry even if I do not have reason to suspect that
our company is being attacked using fake certificates right now.
On one hand, I cannot estimate the risk of any employee at any CA being bought
to issue fake certificates but considering the number of CAs I think this
issue is not entirely academic. On the other hand, fixing this, at least for
the simple case of internal communications, would be exceedingly simple, so
simple that it really does not make sense not to do it (e.g. by static
policies set at the client).
It is probably also worth looking into how to reduce this sort of risk for
external communications, as mentioned by Kyle Hamilton, but that is an
entirely different issue which will need a lot more thought I guess.
Regards,
Balint Balogh
Anders Rundgren
someone incorrectly claiming to be associated with a certain entity. There are no
technical solutions to that today and (AFAIK) nothing on the horizon either.
Regarding trust management on client machines the only reasonable solution
is that machines are locked-down by IT to make it more or less impossible to
perform such by employees. This is a much worse problem for consumers
since they have no IT to cling to. OTOH, S/MIME is a totally useless
security system anyway so I don't really see this as a real-world problem.
1 Bn+ use SSL encryption on a frequent basis, while the S/MIME counterpart
is at least 3 magnitudes below in usage although these system were fiounded
about the same time. That sort of says it all IMNSHO.
AR
Hello
Regards,
Balint Balogh
Anders Rundgren
PKCS 12 file including the private key to the EE cert.
When I import it in MSIE 6 I get the question if I want to install the root CA.
In FF I don't get any question about that and the root is indeed installed as well.
IMO there are a number of issues here; some are specific to the particular clients
and some are generic.
In principle I don't think that a EE certificate or yours (including path) has anything
to do with your trusted parties. That the root was supplied could be due to the
fact that it may be a good idea to supply the entire path, at least to new
contacts.
That FF automatically made the root trusted is a bug or a feature. I would
claim that it is a bug because if somebody like a community distributes a
certificate it is because *they* want you to use a certificate. That is not
the same as you trust their roots for everything including SSL certs which
I guess this feature will enable as well.
That signText required the EE cert to be trusted as reported before is
IMO a clear bug. There can be no *requirements* for having any
CA certs because that is a relying party issue.
In the US Higher Education PKI TAG they are reportedly working
with Mozilla to change a related thing which they claim is a bug.
They claim that ThunderBird does not read the cert-path when
supplied in P11 interface. IMO there is no standard that says
that you should or must do that.
password for the enclosed p12 is: testing
comments?
Anders
Nelson B
> I created a certificate path consisting of root CA, sub CA and EE cert and
> put it in a PKCS 12 file including the private key to the EE cert.
>
> When I import it in MSIE 6 I get the question if I want to install the root
> CA.
>
> In FF I don't get any question about that and the root is indeed installed as
> well.
Just installed? Or installed and marked trusted?
Are you certain that the cert was marked trusted? Or did you merely
observe that the cert appeared in the Cert Manager's CA cert page?
The presence of the cert in the Cert Manager's CA cert page does NOT
mean that it is trusted.
The mere fact that a cert is stored in FF cert store doesn't mean it is
trusted. In fact, certs can be stored for the explicit purpose of
recording that they are known and *untrusted*.
To see if a cert is trusted (in FF's cert manager) you must go to the
"edit trust" page for that cert and look at the trust check boxes.
> In principle I don't think that a EE certificate or yours (including path)
> has anything to do with your trusted parties. That the root was supplied
> could be due to the fact that it may be a good idea to supply the entire
> path, at least to new contacts.
Well, it's certainly disingenuous to expect others to trust a CA cert to
validate your EE cert, when you yourself do not trust that CA cert.
When using a "user" cert (an EE cert for which you have the private key)
for signing, NSS does not require any trust on the cert's chain. The
fact that you have the private key is enough for NSS to perform the
signature, and send out the cert chain for that EE cert (as much of the
chain as NSS can construct).
PSM (the glue for NSS in FF/TB/SM) may have chosen to implement a policy
of requiring valid cert chains (leading to trusted roots) in order for a
cert to be considered (by PSM) a valid candidate to be used in signing.
I can't speak for PSM.
> That FF automatically made the root trusted is a bug or a feature.
If indeed the root was actually marked trusted, I think that's a bug in PSM.
> I would claim that it is a bug because if somebody like a community
> distributes a certificate it is because *they* want you to use a certificate.
> That is not the same as you trust their roots for everything including SSL
> certs which I guess this feature will enable as well.
NSS separates trust by usage. A cert may be separately trusted for SSL
server use, for SSL client auth use, for SMIME use, and for code/object
signing use.
> That signText required the EE cert to be trusted as reported before is IMO a
> clear bug. There can be no *requirements* for having any CA certs because
> that is a relying party issue.
On the contrary. When generating a signature, the user wants to be assured
that the recipient will be able to verify the signature. That involves
ensuring that the signature is sent with a complete and valid cert chain.
The only way that NSS has to know that a cert chain is complete and valid
is to validate it. That, in turn, requires having a trust anchor.
So, I think that PSM (signtext is part of PSM, not NSS) may require a
validatable cert chain in the course of operation.
> In the US Higher Education PKI TAG they are reportedly working with Mozilla
> to change a related thing which they claim is a bug.
I'm not aware of any such request from those folks.
Maybe they've make this request more-or-less anonymously.
Can you/they cite a bug number? All bugs/RFEs are recorded in bugzilla.
We don't keep bugs/RFEs "off the books".
> They claim that ThunderBird does not read the cert-path when supplied in P11
> interface.
What does that mean? That TB doesn't read certs out of tokens?
> IMO there is no standard that says that you should or must do that.
Well, we try to do it. :)
Some third party PKCS#11 modules have problems (understatement of the year).
One of the more common problems is making the CKA_ID attributes of the certs
match the CKA_IDs of the private keys. Another is returning object IDs
from C_FindObjects that cannot then subsequently be accessed by the returned
object ID. In short, if this is a problem with some token's PKCS#11 module,
it's probably a module problem. We don't fix third parties' modules, though
they often request that we do.
> password for the enclosed p12 is: testing
This list doesn't forward attachments unless they're text/plain.
If you've verified that the root cert is added and actually marked trusted,
then you should file a bugzilla bug against PSM, and attach your p12 to it.
In bugzilla, PSM is product=core, component="security: PSM".
--
Nelson B
Anders Rundgren
c-i-l
"Nelson B" wrote:
>> I created a certificate path consisting of root CA, sub CA and EE cert and
>> put it in a PKCS 12 file including the private key to the EE cert.
>>
>> When I import it in MSIE 6 I get the question if I want to install the root
>> CA.
>>
>> In FF I don't get any question about that and the root is indeed installed as
>> well.
>Just installed? Or installed and marked trusted?
<snip>
>To see if a cert is trusted (in FF's cert manager) you must go to the
>"edit trust" page for that cert and look at the trust check boxes.
You were quite right. It was NOT trusted.
Conclusion: IE and FF are entirely different in this respect which certainly is not
making things simpler. That does not mean that IE is right or the opposite :-|
>> In principle I don't think that a EE certificate or yours (including path)
>> has anything to do with your trusted parties. That the root was supplied
>> could be due to the fact that it may be a good idea to supply the entire
>> path, at least to new contacts.
>>Well, it's certainly disingenuous to expect others to trust a CA cert to
>>validate your EE cert, when you yourself do not trust that CA cert.
Have you ever tried that phrase on consumers? They don't know what a
CA is and I hope they never will. Note. I'm not talking about S/MIME
because S/MIME is a marginal technology that has no validity whatsoever
in the consumer space.
>NSS separates trust by usage. A cert may be separately trusted for SSL
>server use, for SSL client auth use, for SMIME use, and for code/object
>signing use.
OK, sound good.
>> That signText required the EE cert to be trusted as reported before is IMO a
>> clear bug. There can be no *requirements* for having any CA certs because
>> that is a relying party issue.
>On the contrary. When generating a signature, the user wants to be assured
>that the recipient will be able to verify the signature.
This is quite different to how most similar software work. Commercial
signature software for browsers, usually filter EE certs because that is the
only thing need for on-line signatures. If the relying party does not
*immediately* recognize the EE cert or the signature is broken, it will puke
on the signature in the same way as for SSL client-auth. e-mail is something
rather different but the requirement you are mentioning is not universally
implemented AFAIK. To make it even more "fun" there are quite a few
CAs that consider their root as secret. You have to *pay* to get see it.
I don't say that this is good or so but it is important to know that
on-line is an entirely different thing than off-line because in on-line
signature scenarios users do not have to verify or trust anything but
SSL server certs.
>> In the US Higher Education PKI TAG they are reportedly working with Mozilla
>> to change a related thing which they claim is a bug.
>I'm not aware of any such request from those folks.
>Maybe they've make this request more-or-less anonymously.
>Can you/they cite a bug number? All bugs/RFEs are recorded in bugzilla.
>We don't keep bugs/RFEs "off the books".
I will transfer this information back so that they do it properly.
<snip>
Anders R
Nelson B
> Have you ever tried that phrase on consumers? They don't know what a
> CA is and I hope they never will.
Ah, then apparently you hope consumers will never get certs.
Thanks for clarifying your position.
> Note. I'm not talking about S/MIME because S/MIME is a marginal technology
> that has no validity whatsoever in the consumer space.
Why do you keep saying that?
Trolling?
Hoping to provoke NSS developers?
Trying to make friends in the mozilla community by belittling its capabilities?
Trying to persuade TBird users to stop using it?
I'd say you're not succeeding on any of those objectives.
Anders Rundgren
>> CA is and I hope they never will.
>Ah, then apparently you hope consumers will never get certs.
Maybe you are not familiar with consumer/citizen PKIs in the EU? They
are mostly designed for on-line services. For such services you don't need any
client-level CA support for EE-certs like you don't need VISA's license in
order to use a VISA credit-card. It is enough to recognize the logo so you
don't use your library card. Because it is a human-to-service operation
where the service is usually fully automatic,. That is, consumers may know
the brand of certificate but not the terms CA, trust anchors etc. In the EU
it is called eID and that's about it.
>Thanks for clarifying your position.
This in not my "position", I'm merely trying to make people understand that
even if S/MIME and on-line use PKI, their requirements are different. In
the Mozilla camp these differences have not [yet] been acknowledged.
>> Note. I'm not talking about S/MIME because S/MIME is a marginal technology
>> that has no validity whatsoever in the consumer space.
>Why do you keep saying that?
A lot of people agree with me but they [usually] express it differently:
http://middleware.internet2.edu/pki06/proceedings/hallam-baker-email_usability.ppt
SSL and S/MIME were created a decade back or so. Server-side SSL is currently
used by the entire Internet community while maybe 1% use signed e-mail and probably
only 0.01% use encrypted e-mail. It is the latter thing which is the biggest problem.
>Trolling?
>Hoping to provoke NSS developers?
>Trying to make friends in the mozilla community by belittling its capabilities?
>Trying to persuade TBird users to stop using it?
What could I possibly gain by doing that?
It is good enough that very few governments and probably not a single bank use or intend
to use S/MIME on *major* scale for *external communication*. Web-based services
have compelling advantages such as:
- No client to install
- No encryption keys to backup or escrow
- Interactive services are more useful than async e-mail
- No encryption key lookup issues
Due to this, it does not matter how much energy the Mozilla community put into the
TBird S/MIME, it will not change the core issue which simply is "usability".
Mozilla could rather spend this energy on on-line signatures because these are more
in demand, at least in the EU. signText is not good enough.
Secure e-mail in a G2C (Government to Citizen) has recently begun to be realized
using web-based "mail-boxes" to which you login using client-SSL-auth.
e-mail is used as a notification option. Encryption is for free. Who could ask
for more?
I know that the US government loves S/MIME but OTOH after a decade of
Fed-PKIing you still can't send an encrypted e-mail to a government agency
like IRS, and it is really the S/MIME.*architecture* that is the culprit.
My "I hate S/MIME" rant:
It is really the security architecture of e-mail, the extremely hard-to-deploy
S/MIME mechanism that is the primary reason to why our mail-boxed are
flooded with spam, phishing and viruses. If the people who created secure
e-mail had understood the difference between a community and the internet,
they would have designed a system that as a minimum would secure messages
at the mail-server level. This is not end-to-end security but it is affordable,
implementable and scalable. Consequently the financial sector only use such
solutions, otherwise international and cross-bank payments would still be manual.
Using such a scheme encryption and message signing becomes default.
Anders
Anders Rundgren
1. Mozilla PKI client support (FF's TLS-client-auth, FF's signText and
TB's S/MIME), requires that the CA certificate is known and trusted
by the local client software?
If that is true I would consider it a major bug or at least a major nuisance
because there is no smart card standard AFAIK that requires the card
to contain anything but EE certs and associated private keys.
2.Even if cards were equipped with the entire cert-path the user would
anyway have to edit trust or similar?
Particularly for FF, the point with such a requirement is counterproductive
since it makes the card non-mobile.
Anders
Bob Relyea
>Have I gotten this right?
>
>1. Mozilla PKI client support (FF's TLS-client-auth, FF's signText and
>TB's S/MIME), requires that the CA certificate is known and trusted
>by the local client software?
>
>
No, TLS-client-auth only requires enough of the chain to recognize the
CA certs the server sends over FF filters the certs based on the
certificates. The client filters certs it believes the server will trust.
I don't know about signText, I'd have to look (This is all PSM code, but
my guess it's similiar to the SSL code).
In the S/MIME case, unless you are part of an infrastructure, your cert
and key is pretty useless anyway (if you don't have the trust anchor,
it's likely the person you are talking to doesn't either).
>If that is true I would consider it a major bug or at least a major nuisance
>because there is no smart card standard AFAIK that requires the card
>to contain anything but EE certs and associated private keys.
>
>
If you have a smart card and are doing email one would hope the certs on
those cards were issued by a CA you already trust. (Not just S/MIME, you
need to be able to establish trust even in PGP cases, the latter is just
a weaker binding, but is still the same principle).
>2.Even if cards were equipped with the entire cert-path the user would
>anyway have to edit trust or similar?
>
>
The EE cert should be issued by a CA the user already trusts. There are
CA companies that will issue you an appropriate intermediate (GeoTrust
for one).
Of course in the SSL client auth case, you just need to chain to a cert
the server trusts. I have built several demos where the back end Server
is the only one that trust a particular CA which a smart card is issued.
FF quite happily will use the cert from the smart card even though it
doesn't trust the cert itself. It should be easy enough to try for yourself.
>Particularly for FF, the point with such a requirement is counterproductive
>since it makes the card non-mobile.
>
>
I hope that explanation helps. SignText and SSL client auth are
particular cases since the trusted party is a limitted to the back end,
so your model of the client not needing a trust anchor is correct. Email
is different and requires some sort of means to get a trusted anchor
(PKIX and LDAP can help here, and is the current thinking among those
with big enough infrastructures to care).
bob
Anders Rundgren
Apparently it does not accept the NR bit either.
Essentially the whole filtering thing is upside-down. In an on-line scenario
it is the relying party that should specify what kind of clients certs that
it will accept. The crude scheme featured in TLS is though not granular
enough for this purpose.
a.
----- Original Message -----
From: "Mikolaj Habryn" <dic...@rcpt.to>
To: "Bob Relyea" <rre...@redhat.com>
Cc: "Anders Rundgren" <anders....@telia.com>; "Mozilla Crypto" <dev-tec...@lists.mozilla.org>
Sent: Monday, September 11, 2006 08:38
Subject: Re: The Mozilla trust model & FIPS201
On Sun, 2006-09-03 at 17:53 -0700, Bob Relyea wrote:
> Of course in the SSL client auth case, you just need to chain to a cert
> the server trusts. I have built several demos where the back end Server
> is the only one that trust a particular CA which a smart card is issued.
> FF quite happily will use the cert from the smart card even though it
> doesn't trust the cert itself. It should be easy enough to try for yourself.
Sorry, very late reply. The above doesn't work for crypto.signText,
which calls CERT_VerifyCert on the certificate it's attempting to sign
with, which bombs if the browser lacks a valid trust chain. Comes back
with an error:internalError in Javascript. I wound up instructing users
to load the CA certificate and mark it as trusted for email.
m.
wof
I'm currently writing an extension for firefox that checks a fingerprint
from a SSL-Certificate against the stored fingerprint for a configured
domain. If the fingerprint does not match a warning appears. This extension
should support a trusted anchor without a CA like verisign and could be used
to secure for example home banking sites.
The extension is currentliy in pre-alpha phase and the next month I don't
have much time to work on it. So maybe begin next year you may see it.
greetings
wof