A quick note before I go off to work: I'm about to conclude that
modifying draft 10 of the CA cert policy to mandate additional CA
requirements is not going to work; in the words of the IETF we have
neither "rough consensus" nor "working code". Therefore I'm at present
planning to move forward as follows:

I'm going to use draft 10 as a base, with the following proposed additions:

* Modify clause 6 ("We require that all CAs...") to add a final
paragraph as follows (or make this a new clause 7):

   In addition, we reserve the right to not include a CA's
   certificate(s) in cases where we believe that doing so would
   cause undue risks to users' security *or* cause technical
   problems with the operation of our software.

* Add a new clause 12 as follows:

   12. We will appoint one or more persons to make decisions
       on our behalf to evaluate CA requests and make decisions
       regarding them. CAs or others objecting to a particular decision
       may appeal to mozilla.org staff, who will make a final decision.

Language needs to be tweaked for style, etc., but this should give you
the general idea.

The underlying idea here is that IMO it will be difficult, nay
impossible, to write and (especially) implement the policy without
making subjective decisions, either in general or about a particular CA.
Therefore I believe it's necessary to acknowledge that in the policy, to
give us (and especially me, if I'm making the decisions) the "wiggle
room" necessary to address potential concerns.

In particular, I intend the added language in clause 6 to address the
concerns of Nelson and others about rogue or incompetent CAs "slipping
through" based on meeting the mere letter of the requirements (e.g., a
CA with an extremely loose CPS attested to by an auditor willing to take
the money and run, or a CA that generates certs that crash or otherwise
hork up our software).

However if you're going to introduce subjectivity (which I think is
inevitable) then IMO you also have to accompanying that with
transparency and accountability, so that a) you know what's going on
with regard to the decisions that are taken, and b) you have a channel
to make complaints if you think a decision was botched.

I think transparency is already adequately addressed in the policy; see
for example clause 2 ("public process"), clause 6 ("publicly disclose",
"published criteria"), clause 8 ("sufficient public information"),
clause 9 ("publicly disclosed"), and clause 13 ("consulting with the
public Mozilla community"). However the policy did not make clear who
would be making decisions and how to complain about them, which is why I
added the proposed new clause above.

(In practice we should add a link to some other page like the module
owners page to identify the actual person making decisions, whether me
or someone else.)

That's it for now. My plan is to make the above changes in draft 11
(tmomorrow if I have time), and then submit that to the Mozilla
Foundation for final approval a day or two after that.

Frank

--
Frank Hecker
hec...@hecker.org

working code?  We have plenty of working code.  No additional working
code is needed to place a "floor" on CA requirements.

 > Therefore I'm at present planning to move forward as follows:

Well, it seems that after a year, we've come full circle.  IIRC, one of
the reasons for adopting the webtrust model in the first place was to
get mozilla OUT of the business of making subjective decisions.
Why do you now wish to reverse that?

Nothing I've ever read about WebTrust audits (or heard from people I
know who have undergone them) suggests that WebTrust has any "floor"
of requirements.  The CA states its policy, and the auditor attests
that it meets its policy.  I've heard that if a CA has no stated policy
on certain issues, the auditor may request/require that the CA write one,
and then check to see that it is followed.  But nothing I've heard says
that the auditor can impose a minimum policy.

The phrase "take the money and run" might apply to an auditor that failed
to hold a CA to its own policies, but not to an auditor who rightly
attests to a CA that does adhere to its own policies, no matter how low
they may be.  In the absence of a floor, for an auditor to withhold
attestation when a CA does meet its own policies would probably be an
"actionable" offense.

You wonder if this is merely a "good thing" or if there is real cause
for concern.  There is real cause for concern.  I will write you
privately about it.

 > or a CA that generates certs that crash or otherwise hork up our software).

Yeah, it's good to have an out for that.  :-)

I don't see it as inevitable.  Impose a floor, an objective one.
You've proposed one, described as "the LCP from TS 102 042".
I've not seen that document, so I cannot speak to its suitability,
but if you think it meets my concerns, I'd say we should use it as a
starting point for the floor.

Well, that's probably a good idea whether or not there is subjectivity.

Also a good idea.

I will write you privately about my motivation for wanting a floor..

--
Nelson B

I would make that even more lopsided in MF's favour.
Something like "

  "We reserve the right to not include a CA's certificate(s)
   for any reason and in our sole determination.

  Cases may include but are not limited
  to cases where we believe that doing so would
  cause undue risks to users' security *or* cause technical
  problems with the operation of our software."

Or something.  (I haven't the URL in front of me, I should
check that to see it isn't already there...)

Might help to give that person(s) a name.

"MF will appoint a 'CA coordinator' to make decisions
regarding all matters concerning CAs  ..."

Good stuff!

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Sorry, I was speaking metaphorically: By "working code" I mean a clear
set of "minimum assurance" criteria which we can use to sort CAs into
the "good -- approve" and "bad -- reject" categories.

I'm not reversing it, I'm simply acknowledging that there will likely
always be a set of cases where subjectivity will still be called for.
Adopting WebTrust, X9.79, TS 102 042, etc., greatly reduces the number
of such criteria we have to come up with and the corresponding decisions
we have to make, so I think it was useful to include them, as opposed to
going off and coming up with our own criteria on how CAs should operate.
However there is still a grey area and I think it's going to be hard to
further reduce it.

And (without identifying the exact nature of your concern) I will repeat
what I wrote to you, which is that I find it difficult to figure out
from a policy point of view to exclude the particular case (or cases)
you're concerned about, without introducing an element of subjectivity
that amounts to saying "we don't think this is a good idea, even if
everybody else -- auditors, subscribers, relying parties, whoever --
have signed off on it".

Frank

--
Frank Hecker
hec...@hecker.org

(I've changed the subject line to better reflect the direction I'm
taking this discussion.)

Nelson B wrote re the alleged inevitability of subjectivity in
evaluating CAs:

OK, I've thought about this some more, and I'm going to "think out loud"
here, in the hopes that this may lead to some progress on this issue; my
apologies for rambling on at length:

With regard to CAs I think we can usefully divide the issues into two
general areas: how CA's vet subscribers (i.e., people applying for
certs), and how CAs operate in other respects (e.g., signing key
protection, continuity of operations, etc.). Let's also assume for the
moment that in practice we don't need to worry as much about CA
operations issues if the CA has completed audits/evaluations according
to the WebTrust, X9.79, or ETSI criteria.

(Some might question that assumption, but I think there's more
controversy around subscriber vetting, since it's so closely related to
the phishing threat, so I'm going to focus on that for now. Also, it's
possible that the LCP in ETSI TS 102 042 may be suitable as a "floor"
for CA operations-related issues apart from subscriber vetting; I need
some other people's opinions on this. But in any case I need to bound
the problem at hand in order to make progress.)

With subscriber vetting I think we can classify potential sources of
concerns into three cases as follows, using SSL certs as an example
since it's relevant to the phishing problem; I've given each of the
following three cases names so that I can easily refer to them later:

Case 1 ("CA knows otherwise"): The CA knowingly issues server certs to
entities who do not own the domains in question and are not otherwise
acting as authorized agents of the domain owners. (For the sake of
argument we're assuming here that such issuance is not contrary to the
CA's stated policies, and hence it's conceivable that the CA might be
able to pass an audit/evaluation focused on the CA's compliance to its
policies.)

Case 2 ("CA knows nothing"): The CA does absolutely no checking
whatsoever that applicants for a server cert own the associated domains
(or are acting as authorized agents for the domain owners); in practice
the applicants might or might not own the domains, the CA doesn't know
either way. (Again, we assume that this is per stated CA policy.)

Case 3 ("CA doesn't know enough"). The CA does some amount of checking
to verify that applicants own the domains (or are authorized agents),
but in our opinion what the CA does is "not enough", however we define
that. (And again we assume that whatever the CA is doing is per its
stated policies.)

For each of these cases our concerns are really with the substance of
the policies under which the CA operates, not whether or not the CA is
operating in accordance with those policies.

Now we could certainly try to say in our policy that certain CA policies
are not acceptable and would be grounds for rejecting the CA. But first
let's take each case in turn and look at three questions:

1. Is the CA behavior in question definitely something we want to reject
categorically, or are there CA use cases that we'd consider legitimate
and relevant, at least as far as typical users are concerned?

2. How would we craft policy language to accomplish rejection of
illegitimate use cases (i.e., illegitimate from our point of view) while
not rejecting legitimate use cases?

3. Are the provisions of our policy in sync with the nature of the
respective threats?

I'll consider each case in turn.

"CA knows otherwise"

This case seems like it's uniformly a bad thing; after all a CA
operating under a "knows otherwise" policy would deliberately and
knowingly issue me or anyone else an SSL server cert for www.paypal.com
or www.citibank.com whatever. Thus a policy that rejected "knows
otherwise" CAs would be consistent with protecting typical users against
a plausible threat, namely phishing attacks.

This case is also pretty straightforward to craft policy language for;
the key is the "knowing" nature of the CA's actions, which in this case
would presumably be disclosed in the Certificate Policy or Certification
Practice Statement. (Otherwise the CA would be acting contrary to the
CP/CPS, and should not be able to pass an audit/evaluation.) "Knowing"
and "knowingly" are good policy words: their meaning is reasonably clear
and (at least as used here) is not much subject to interpretation.

Would rejecting "knows otherwise" CAs inadvertently have a negative
impact on legimitate uses? For example, way back in my early days in
Netscape, when SSL was still new, a prospective customer asked me if
there was a way they could monitor their employees' network activities,
including in particular outbound SSL connections from their network to
external networks. (I'll leave the organization unnamed, for obvious
reasons.) I of course informed them that this was contrary to the nature
of SSL, which was intended as an end-to-end protocol. However it's also
possible to imagine such an organization setting up a special proxy
server inside their firewall that didn't just do SSL tunneling (as in
standard proxies), but rather served as a terminating point for SSL
connections, with the proxy then initiating separate SSL connections to
the true end destinations.

In implementing this setup (which really amounts to an authorized MITM)
the organization could have the proxy impersonate the true end points,
in the sense of returning SSL server certs that appear to be associated
with the external servers/domains, but are actually tied to a private
key on the proxy and issued by the organization's own CA. Employees
would of course have installed the organization's root CA cert in their
browsers, have configured the proxy, and presumably also have consented
to monitoring.

Now, what would we do with a (hypothetical) request to add this
organization's CA cert to Mozilla/Firefox/etc? Well, we could certainly
reject it as not being relevant to typical Mozilla users, being an
intranet CA and not a public CA. Even if it were an Internet-based
service then it's still arguably not relevant to typical users, since
the only people who would really need the cert are people configured to
use the proxy in question.

However we'll go an extra step and assume for the sake of argument that
the CA in question issues "real" certs of interest to typical users, in
addition to the "fake" certs described here. If we still wanted to
reject including this CA cert (and I presume we would, based on the
phishing-related concerns) then we'd need either "catch all" language as
I've previously described (i.e., to allow rejection based on general
security concerns) or a specific policy provision applying to the "CA
knows otherwise" case.

Are there other possible "CA knows otherwise" use cases that at least
some people might consider legitimate, and that a policy might have to
allow for? I don't know -- my imagination is probably too limited. But
I'll assume for now that the answer is "no", and that having our policy
specifically address the "knows otherwise" case is both possible and
desirable.

"CA knows nothing"

Now let's turn to the case where the CA does not vet subscribers at all,
so, for example, subscribers are free to apply for an SSL server cert
under any domain name whatsoever. The practical effect in terms of
enabling potential phishing attacks is pretty much the same, but the
underlying CA intent may be different, so I've classified this as a
different case.

(Not that I'm considering legal issues here, but this distinction is
reminiscent of the distinctions that people draw in the case of P2P
systems between a P2P network provider knowingly infringing copyrights
and such a provider simply providing a service with no detailed
knowledge about what people are using it for. Some people -- like
lawyers for the RIAA -- claim that this is a distinction without a
difference, but I and others would disagree, given the potential for
subtantial non-infringing uses of P2P networks -- like distributing
copies of Firefox.)

Given the implications for phishing, one could argue that we should also
reject a CA whose policies permit "knows nothing" issuance of certs. How
could one do so in terms of the policy language (considering only the
SSL server case for now)? Perhaps we could require that CAs implement
"reasonable measures" to verify that applicants own the domains
associated with the certs (or are acting as authorized agents for the
owners). What exactly are "reasonable measures"? That's subjectivity
creeping in again. To go beyond that we really move into the area of
implementation and what is "enough" vs. "not enough", so I'll postpone
that discussion to the next and final case.

(Incidentally, this is another reason why I'm treating the "CA knows
otherwise" case as different from the "CA knows nothing" case, because
the relevant policy language would be different.)

If we decided to reject CAs with "knows nothing" policies, could that
negatively impact legitimate use cases relevant to typical users? One
possible legitimate use case I can think of is a free Internet-based
"test CA" service that crypto developers can use to get arbitrary certs
generated for use in testing their PKI-enabled software. We could
certainly reject such a CA's application (assuming we wished to do so)
based on it's not being relevant to typical Mozilla users. What if this
test CA were combined with a more typical CA under the same root? Then
we're in the same situation I described with the "CA knows otherwise" ...

read more »

I think the first 2 can be lumped together, but different in the
reasoning you gave, I don't think you can have security without some way
to identify a certificate to a person/organisation/website etc. What I
mean by this even simple email pings to verify the person has some kind
of link to the domain.

So in both the first 2 cases no form of vetting occurs or is blatantly
ignored and this is as you put it completely open to exploits/social
engineering etc, and "a very bad thing(tm)" as it would be worst for
general user security then any possible benefit for a minority (namely
scammers and spammers), so I agree in whole with your summary that both
should be excluded from inclusion even if they have passed an audit...

I'll save comment for your third email...

--

Best regards,
 Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."

Here I am again. Now for the hard part, proposing particular policy
language to flesh out the points above. Rather than ramble on in an
attempt to come to a conclusion, I'll present my conclusions first and
then explain my motivations afterward.

So, without further ado, if we do have policy language on vetting CA
subscribers I think it should look as follows (I'll propose more
detailed language in a future message when I have time, but this will
have to do for now):

* For SSL server certs the requirement should be something like "the CA
must take reasonable measures to verify that the entity owns the domain
associated with the certificate" and "the CA must not knowingly issue
certs to entities who do not own the associated domains". (The language
also has to address the question of agents who are authorized to get
certs on behalf of the someone else; we'll skip that for now. We'll also
postpone for now the issue of what is "reasonable" and what is not.)

* For email certs the requirement should be something like "the CA must
take reasonable measures to verify that the entity controls the email
account associated with the certificate" and "CA must not knowingly
issue certs to entities who do not control the associated accounts".
(Again, we'll skip for now the issues of agents and what is "reasonable".)

* For object signing certs the requirement should be something like "the
CA must take reasonable measures to verify the identity of the entity
associated with the certificate" and "CA must not knowingly issue certs
to entities whose identities are different than those of the entities
named in the certs". (Again, we'll skip for now the issues of agents and
what is "reasonable".)

(Note that I'm ignoring for now the issue of CAs issuing certs that
might be confusing to users, e.g., an object signing cert for a company
"Micros0ft Corporation". One can of worms at a time is quite enough for
me, thank you very much.)

Why did I choose these particular requirements? Let's take each of the
cases in turn:

SSL server certs

Here the primary threat of interest is clearly phishing, and if CAs and
SSL are to protect against phishing at all then at a minimum there must
be some assurance that only the owner of a domain can get a cert for
that domain. Otherwise having the user compare the domain name in the
address bar and the domain name in the status bar (as recommended for
Firefox) is of no use, since if someone can spoof the address bar domain
name then they can trivally get a cert to match the spoofed name.

Why not go further and require definitive proof of identity? Arguably
this is a) a secondary consideration, b) not necessarily possible in
some contexts, and c) overkill for some use cases.  Taking these in turn:

Identity of the domain name owner is arguably a secondary consideration,
because our primary consideration is ensuring that the "cert owner"
(i.e., the entity possessing the private key associated with the cert)
is the same as the domain owner, and you don't necessarily need to use
identity per se to confirm that. (For example, you could verify that the
cert applicant both possesses the private key for the cert and also
controls the email account listed in the whois registry as being
associated with the administrative contact for the domain.)

Second, as noted previously identity documentation and ways of
evaluating it can vary from country to country. It's possible in some
cases that verification of identity, and trying to prove "cert owner" =
"Foo" and "Foo = domain owner" would be less useful and straightforward
than trying to prove  "cert owner" = "domain owner" more directly (as in
the example above). (Unlike identity, we do have a single global system
for domain name registration, however poorly people may feel it works
sometimes.)

Finally, proof of identity is arguably overkill for some legitimate and
relevant use cases. For example, we've previously discussed the use
cases involving IMAP/SSL, SMTP/SSL, etc., where the relying parties
(i.e., the people with IMAP/SMTP mail clients) would have a prior
relationship with the cert applicant (i.e., the entity running the IMAP
or SMTP server) and you wouldn't necessarily need strong identity
checking by the CA. If strong identity checking is always required for
SSL server certs then it would have to be extended to cover this use
case as well (for reasons discussed earlier), and this might negatively
impact this use case, by "raising the bar" for operators of IMAP, etc.,
servers.

Requiring strong identity checks for the IMAP/SSL use case "raises the
bar" because it means operators of IMAP/SMTP servers either have to pay
more for CA certs to cover the costs of additional identity checking
that is arguably not needed for this use case, or they have to operate
their own CAs, which is not a trivial task. The net effect is that this
discourages the adoption of IMAP/SMTP, etc., over SSL, and thus
negatively impacts typical users who might benefit from their email
service providers adopting SSL for use with email protocols.

Email certs

Here again the primary threat of interest is phishing, and if CAs and
SSL are to protect against email phishing attacks at all then at a
minimum there must be some assurance that only the person controlling an
email account can get a cert for that account. Otherwise having the user
(or the email client) compare the email address in the "From" field and
the email address in the certificate is of no use, since if someone can
spoof the From field then they can get a cert to match the spoofed from
address.

Why not go further and require definitive proof of identity of the
person or entity associated with the email account? Because as with SSL
server certs this is arguably a secondary consideration, not necessarily
possible in some contexts, and overkill for some use cases.

In the Internet identity per se has never been tightly coupled with
email accounts and email use. I communicate (every day it seems :-) with
entities like "Nelson Bolyard", "Ian G", "Gervase Markham", "Duane",
etc., without having ever met them or having the least idea if their
real-life identities match their online identities. (Well, I did meet
Nelson once IIRC, but I certainly didn't check his drivers license or
passport, so I have no idea if I was meeting the real Nelson or a false
one.)

As with the IMAP/SSL use case, IMO there are perfectly legitimate and
relevant email use cases, like communication among friends, where
requiring strong proof of identity would arguably negatively impact
typical users in the context of those use cases. (Again, this is because
requiring strong identity checks requires potential email cert users to
pay more for certs to cover the additional checks, to go outside the CA
system -- e.g., by using PGP-style systems -- or to use unsecured email.)

Object signing certs

With object signing certs we are also concerned with the possibility of
phishing in the sense of tricking users into installing unwanted and
potentially malicious software based on the users' perception that the
software is from a known and trusted source. Unfortunately in the object
signing case we have no independent mechanism for which the cert is
serving as a cross-check (as the SSL cert domain name does for the
address bar, and the email cert address does for the From field). The
only thing the user has as information is what's in the cert itself.

(I've previously proposed that at least for MF-distributed software we
consider providing such an independent mechanism, by tying MF-owned
object signing certs to MF-controlled domains. Thus, for example, we
might have Firefox accept a MF-signed FF extension for installation only
if it has been downloaded from the updates.mozilla.org site. However
this is not applicable to object signing in general, at least as
practiced today. See also my comments below regarding related proposals.)

Since the user has to rely solely on information in the object signing
cert, arguably that information needs to be as correct as possible. At a
minimum this means providing strong assurances of the identity of the
entity distributing the software (who might not necessarily be the
developer of the software).

It's also possible to imagine some CAs going beyond that and issuing
object signing certs tied to a particular software object being
distributed, e.g., as ...

read more »

Agents is a big one for email certificates, especially with things like
staff ID badges that are PKI cards as well, in this instance the domain
owner also becomes a sort of mini RA I guess... At least this is how
we're currently dealing with it...

--

Best regards,
 Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."

I would agree in general, but let's see...

Well, you might be lucky in that the audit/evaluation
would pick it up, but I wouldn't rely on that.  For some
large proportion of cases, if the CA operates in this
mode, it will also keep it from the auditor/evaluator.

One problem with this whole discussion is you are trying
to predict a future case, *and* you are assuming that
someone is up to no good, so your conclusion is that once
found out, it is easy to deal with.  Shaky ground.

Yes, consider the Verisign conflict of interest with respect
to their usage of the Lawful Intercept Service:

http://www.financialcryptography.com/mt/archives/000206.html
http://www.financialcryptography.com/mt/archives/000332.html

In that situation, one can say that Verisign could engage in
fake cert issuance knowingly.  And we can pretty much guess
that the auditor would fall into line here.  Further, it is quite
likely that we may have a suspicion of this activity, but the
company itself will be unlikely (due to the court's decree) to
permit any opening or discussion of said activity, we would
never have sufficient proof of anything to support any policy
determination.

Now, is that legitimate?  It's not in the interests of the user,
I think we can make that case.  But, it is in accordance with
the processes of the law and courts, at some level.  So making
a decision based on this is not easy.

I think as a technical cryptographic issue, the purpose of the cert
is to establish the domain name.  This was the pure crypto reason
for its existence, as this closed the alleged MITM hole, whereby
some bad Mallory would sit at another place and pretend to be
both endpoints.

So, if the domain name is not being checked as controlled, then
the cert is no longer performing a cryptographic role.  This does
seem to be at least something to pay slightly more than lip
service to.

Is that included in your "CA knows nothing" case?  Or does the
CA literally hand out certs for Amazon.com to whoever asks?

As far as phishing is concerned, even if the CA knows nothing,
the cert gives that all-important relationship hook.

No, not at all.  With classical phishing, the key to defence
is to map the real cert against any other cert.  Just the
change is enough to base a warning on.  If MinimalCA
issues an amazon look-alike, then the browser still detects
it as being different.

But, there are two phases in browsing, and they are both
distinct:

    1. Introduction
    2. Repeat visit.

Phishing is primarily a weakness in 2, and this can be addressed
with techniques of comparing one cert already known against
another not known.

Yet, if there exist MinimalCerts for given domains, the Introduction,
phase 1., is now wide open to an MITM.  That's not as serious as
fixing phishing, but I can't see the point in winding back the model
so far that Mozilla transparently permits anyone to pretend
to be anyone.

(Such certs are logically equivalent to self-signed certs.  There
is nothing wrong with self-signed certs, as long as they are
presented to the user for what they are.  "This cert is not
signed by anyone important!"  So in a sense, there is no point
in permitting MinimalCerts, because those are self-signed
certs and we already have those.)

OK.

There are huge untapped security usages for MinimalCerts:

   * all of email should start out using MinimalCerts,
      because most email users already know each other
      and already have as much trust in each other as
      they are likely to ever want or can get.
   * code signing can quite happily use MinimalCerts
      just to protect downloads from external hacking
     attacks (a known and rare but actual threat).
   * anyone putting together a test or low volume site
     can use a Minimal Cert and later upgrade if it is
     shown to need any additional protection.

(I'm using the term MinimalCert there to encompass
all three levels of certs discussed, interchangeably.)

...

read more »

Which as Duane points in the real world of SSL certificate is an
excessively common occurence. I propose :
"the CA must issue certs only to an entity that have received
authorization from the associated domains owner"

Well I don't see why we don't want that for the other cases too ?

What I think we need for object signing certs is not to tie X-owned
object signing certs to X-controlled domains, I don't think it makes too
much sense, but an insurance that the CA will process external report
that the software is acting badly, and accept to revoke it based on that
input.

And Mozilla should be preconfigured to download CRL update from such CA.

Email is the clearest example.  You and I are exchanging this
email.  Yet we have not identified each other.  Let's say we
want to use S/MIME so we can exchange encrypted email
because we don't want our sneaky ISPs to read our mail.

To use S/MIME we need CA-signed certs.  To get CA-signed
certs, we might need to identify ourselves.  Why?  What has
my identity got to do with wanting to share encrypted email
with you?

(As a matter of complete practicality, people don't think in
terms of identifying people in normal real life.  Most of the
people I share PGP email with I never 'identify' in any formal
sense.  In fact, I don't think I've ever identified anyone for
any email usage ever at all, and I've done quite a lot of
serious hard-dosh business over PGP.)

For code signing it's the same thing.  I release a lot of code.
I'd like to release it signed (well, maybe).  But I don't want
to have to 'identify' me, and the people who want to use
the code have no need to 'identify' me.  They would rather
just be sure the code comes from me, which is a completely
different thing than knowing who I am.

Other people might have other needs.  If I may drift into
crypto-politics, there are use cases in for example crypto
code - not so many these days thankfully - where identifying
the signer of code could be quite traumatic in the wrong
places & times.

If you ask for insurance from the CAs, I suspect they will
stop selling certs.  Nobody can deal with the liability
aspects of bad software;  especially in today's uncertain
world where security people like Bruce Schneier are
actively suggesting there be legislation on software
liability for producers.

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

I already addressed this, although I understand some people may not
agree with my rationale: As I noted previously, personal identity per se
is not central to the use of email, and IMO it is perfectly legitimate
to have a use case where, for example, I can begin exchanging signed and
encrypted email with john...@example.com based on a) my prior dealings
with john...@example.com using non-secure email (to which the additional
use of signed and encrypted email is a natural extension) and b) the
assurance of a CA that the person who was issued the email cert with
email address john...@example.com is the same person controlling the
email account for john...@example.com.

I realize that some believe that this scenario is somehow insecure (and
hence should be avoided entirely) in the absence of a known real-world
identity that I can attach to john...@example.com (and that he/she can
attach to me), but I just don't accept that argument.

Frank

--
Frank Hecker
hec...@hecker.org

Actually I was thinking about a case where the "knows otherwise" policy
would be enshrined in some sort of official policy, as in the
hypothetical "intranet SSL MITM proxy" I discussed. I realize that CAs
could do this behind the backs of us and the auditors, and no one would
be the wiser.

No, actually I'm not assuming people are up to no good, I'm addressing
the hypothetical loophole of a CA that deliberately issues misleading
certs per its own published policy, and is able to pass a WebTrust or
other audit based on the CA's conformance to that policy. This is to
address the criticism that WebTrust and maybe other audit regimes could
in theory allow CAs to engage in this practice and others of similar
controversy as long as the legalities and formalities were satisfied
(e.g., appropriate language in policies, relying party agreements, etc.).

It's somewhat analogous to the case of a software vendor purveying what
some may consider "spyware", where the vendor is relying on people to
simply click through the EULA ("5. User privacy rights. Without
limitation or restriction, all your base are belong to us.") without
reading or understanding it.

I think it's unlikely that any CA would seek to exercise this loophole
in practice, and IMO we'd have sufficient other policy language to
justify rejecting their request, but if the policy can have greater
clarify on this point then I think it's worth looking at.

I agree that this is an interesting "corner case" that it would be
fruitless to try to address in a policy like this. In fact, after
thinking about it I may just not try to address the "knows otherwise"
case explicitly, but just have it subsumed under policy language
addressing the "knows nothing" case. (Basically, something like "CA must
take reasonable care to ensure that ...")

My "knows nothing" case was in fact intended to cover the case of a CA
that hands out certs for "amazon.com", "paypal.com", "ebay.com", or any
other possible domain name, to anyone who asks. Think of a test CA
instantiation that accepts arbitrary input in a Certificate Signing
Request and simply returns a signed certificate with whatever CN, O, OU,
etc., were provided in the original request.

I'm sorry, I'm not sure what your point was in this sentence. (If it's a
minor point that I would probably agree with, don't bother explaining.)

Yes in theory, but AFAIK the browser does nothing about this change, at
least in the current implementation. But this is really a question for
our friendly NSS developers: Assume a domain www.foo.com and an SSL cert
issued for that domain by a CA "Bar", with a user surfing to that site
on a regular basis. Assume then that someone manages to get the user to
resolve www.foo.com to another site (e.g., through DNS spoofing or
whatever) and that second site presents a "www.foo.com" SSL cert issued
by a separate CA "Baz". Do NSS and/or PSM in any way detect this change?
If so, do they do anything about it?

Again, such techniques AFAIK are not currently implemented in Firefox
et.al., but in any case I don't think that affects the conclusion I
think you're anout to come to.

My understanding here is that you agree that for purposes of our policy
we can and should go ahead and include some sort of language re vetting
of SSL cert applicants to verify domain ownership, secure in the
knowledge that we would not be ruling out any use cases of likely
interest. (As you say, we already have self-signed certs for people who
want to go that way.)

I'm sorry, now I'm confused: If by "MinimalCerts" you mean certs issued
by a CA without subscriber vetting of any kind, then I thought that
above you were saying that any legitimate use case involving such certs
could be just as easily done using self-signed certs.

For example, in the case of email it seems that your goal above could be
accomplished by implementing something like the following: 1. Have
Thunderbird automatically generate a self-signed S/MIME cert upon
installation. 2. By default send a signed message with this cert for any
email sent to people in your address book. 3. Automatically accept
self-signed certs received in response to such signed messages. As you
note, introducing CAs into this scheme would just complicate it for no
obvious benefit.

As noted above I think I'm not going to try to explicitly address the
"knows otherwise" case, but rather have implicitly addressed by language
addressing ...

read more »