Kyle Hamilton wrote:
Ah, comments. (Thank you for taking the time to read my
contributions, by the way.)
No probs! It was a long list. Bear in mind that
nothing long gets read, ever.
Section 4:
...
This suggested clause is for companies that fail their audits.
(What's the point of having an audit if there's no penalty for
failure?)
Indeed. This is a big question. Saying "oh, we'll
boot them out..." is a hopeful answer, until it is
tried.
Section 5:
[We will consider adding certificates for additional CAs to the default
certificate set upon request] of either at least three users of the CA, or
the (one) entity responsible for the operation of the CA[.]
Note: [bracketed sections are wording that already exists]
Please explain that one further. You seem to be suggesting
that three users of a CA's certs could also independently
seek to request addition? Why? Why bother?
Because I'm trying to figure out at what point "widespread value for
Mozilla's customers" is defined and determined. If multiple users
request the addition of a CA, then there's at least narrowspread
[gotta love creating new words as necessary :P] value to be added --
and the fact that there's several users of the CA means that the CA
exists and is actually issuing certificates, even if the policies for
issuance of those certificates and the model policies for issuance
under the ANSI/ISO guidelines mentioned later in the document don't
quite mesh.
I don't think the policy excludes that possibility.
The main reason why I'd not worry about it too much
is that adding a CA is expensive for all parties,
and we don't want to load up the policy for something
that may never happen.
(As long as a CA has a policy of only issuing certificates to
principals that it can authenticate in some manner, and only asserts
the authentication that it can perform, I have no problem. As an
example, let's take the Mozilla foundation: Mozilla can authenticate
anyone who has an @mozilla.org email address, to some degree [even if
it's just 'to be able to update the forwarding address']. So, Mozilla
could create a CA and issue certificates to
[EMAIL PROTECTED], [EMAIL PROTECTED], and have
those certificates used for at the very least email encryption/signing
and SSL web client authentication to any SSL website that accepted the
Mozilla root for client authentication. Same with any other
organization.)
Sure. Anyone can do that. Nobody bothers. The
reason is, because there isn't a problem here to
solve.
Section 6:
Modify: [publicly disclose information about their policies and business
practices (e.g., in a Certificate Policy and Certification Practice
Statement] which generally conforms to the structure of RFC2527 or its
successors[);]
Rationale: If the structure of a document is familiar, it's MUCH easier to
verify conformance to the criteria for CA operations specified in section 8.
Not needed. If the guy in the hot seat is not familiar,
it will take longer. No other feedback is needed.
Who's the guy in the hot seat? The one considering including the CA
certificate in the browser?
OK, yes, the basic concept is that someone is appointed to
manage the policy (that is Frank at the moment) and someone
is appointed to do the work (that was Nelson, but I think
the torch has moved on).
The Policy manager is in a position to accept alternates,
as long as the approach is published and the documents on
which the due diligence are based are published.
Comment: 'stated purpose(s) of the certificates' needs to be defined.
Stated according to what standard? PKIX?
I think this was readily assumed to be the 3 well known
purposes. I don't think this needs to be nailed down.
I respectfully disagree: when I read it, I was specifically thinking
about key policies, such as 'key encipherment', 'key signing', 'client
authentication', 'server authentication', 'key exchange', 'data
encryption', etc. These are assertions made by the CA, in order to
prevent overuse or misuse of keypair, usually in order to ensure that
the length of time that a certificate remains valid coincides with the
useful lifetime of the key.
It may be easily seen/assumed to be the 3 well-known purposes if the
reader is familiar with the Mozilla security layer, but it's certainly
not the case for someone jumping in from the outside.
OK! Frank, if you've read this far, over to you!
Section 8:
These CA operation criteria are only acceptable if there's any kind of
financial underpinning. If there's financial underpinning, SSL domain
certificates are NOT acceptable, for the reasons I got into at the beginning
of this email.
I would state that the currently-stated criteria within the CP1RC to be 'CA
operations which operate within a financial/fiscal context'.
I would create another set of criteria for 'CA operations which operate in a
community/non-fiscal/non-financial context', with much lower entrance
requirements.
?!? What happens when a charity uses a free CACert
certificate to request credit card donations?
There is no way that MoFo can set itself up as the
net's fiscal policeman. This concept doesn't work;
Firefox is a browser, that's all. It simply cannot
know what a FORM is being used for.
"I just typed in 16 numbers, selected two fields from drop-down lists,
put in another 3 or 4 numbers, and another 5 digits." If you can give
me 1 even remotely plausible instance of something that this pattern
matches that doesn't immediately bring into mind "credit card number,
expiration date, CVV2 code, and ZIP code for validation", I will
withdraw my suggestion.
A survey. A quiz. A mathematical lesson.
It may be obvious when written down like that, but
for the programmer, this is a nightmare. Also,
what makes the whole scenario a 100% woftam is
that the attacker has access to your source, your
algorithm, your methodology, and only needs to
change one thing to break the test.
That is, if you say the above, he splits the numbers
into 4 boxes of 4, makes the year field radio selection,
etc etc.
I'm unimpressed with your argument, though. There are ways of dealing
with this -- including a pop-up on FORM submittal saying "Firefox does
not have any way of verifying that this site is anything more than a
fly-by-night webserver, caveat emptor." (Of course, since Firefox
doesn't log what forms have been submitted to by DN in the certificate
in any case, it is fairly moot.)
Consider this: it isn't me that you need to
impress; it is an active, thinking, aggressive,
coding, well funded, dishonest crook that you
need to impress. I'm easy to impress; the
crook, he's hard. Whatever you do, he'll look
at it and walk around it.
However, for all CAs, I would add:
- The Certification Practice Statement structure generally conforms to
RFC2527 ("Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework") or its successors.
As an addition, if it helps, maybe. I think there are
so many ways to run CAs that it is best to be open here.
Like I said, it helps in the evaluation process. (This entire
document is structured to be a "criteria for acceptance" standard. If
there's criteria for acceptance, there's going to be someone in the
hot seat to ensure that the criteria are met before final acceptance
and approval. RFC2527 provides for a fairly standardized template for
CPS's, and I would like to see more pressure put on the world as a
whole to use the de facto standard... I'll be honest, I prefer reading
things in this format because it provides a checklist as to what
assertions the CA makes, and how it protects those assertions against
forgery. I'd rather make it easy for the guy in the hot seat to read
and understand.)
Sure. The problem is that CAs have not gone through
their period of competitive evolution and we simply
don't know how they should best be run. So we have
to open up and accept some dramatic alternates like
CACert, etc, just in case they are "better."
Section 9:
Comment: Explicitly include WebTrust (http://www.webtrust.org) as an example
of an organization which explicitly meets these requirements -- again, I
would stress that these are for financial/fiscal contexts, and not for
general community-type contexts.
I wouldn't trust WebTrust over any other, especially for
finance. So I'm not sure of your point here.
WebTrust is done by the American Institute of Certified Public
Accountants, which members are responsible for the maintenance of
fiduciary requirements. (Ah, now I start bringing out the big words
like 'fiduciary'. From m-w.com: fiduciary (adj): of, relating to, or
involving a confidence or trust: as a : held or founded in trust or
confidence b : holding in trust c : depending on public confidence for
value or currency <fiduciary fiat money>. Since we're discussing the
means by which certificates become trusted, we're discussing a
fiduciary capacity.)
Right. But, what do WebTrust do? Do they have a fiduciary
duty to American users to protect their ecommerce transactions?
If so, why is it that they accept and provide audits where all
they do is check that the CA's own CPS is being followed?
Or, do they have a fiduciary duty to provide CAs with the
necessary certification to sell product?
*I* am unsure. The couple of times I've pointed out what
I believe to be a massive conflict of interest I've been
ignored. So it's not whatever I think they should be doing.
What's a poor user to think? Do they exist? Do they do
something that works for the user? For Mozilla? I think
the jury is out on this question.
(I think we here on this list have settled on saying that
the "black marks" against WebTrusts are at least sufficient
to worry about only accepting them as a sole criterion.)
Section 10:
Comment: Explicitly require the fiscal identity of the competent,
independent party be disclosed to everyone who asks, so that their
credentials may be independently verified.
? Define fiscal identity. Why are you *requiring*
this? What's wrong with showing a user a cert and
saying "if you want fiscal identity, and you see it
here, use it, if you want. If you don't see it,
don't use that cert. As you want!"
The 'fiscal identity' is the identity which must be presented in order
to open a bank account or sue or be sued. I might not have been
completely clear in my suggestion, however; this is only for those CAs
that want to be trusted for fiscal forms submittal.
Hmmm. (Well, I'll skip the obvious exceptions.) OK,
I entirely agree that we should support those CAs that
want to push these concepts. As long as other CAs are
capable of pushing other concepts, that's grand.
(There's a concept here: MoFo can't be a financial police organization
by any means. However, by providing a means for certificates to be
trusted without any warnings or pop-ups of who the party at the other
end is, and NOT following through on its commitment to notify its
users when something's fishy about a given form's submittal, the MoFo
is violating the trust of its users, and the trust of those people who
would rather be able to say that Firefox is 'better than' MSIE from a
security standpoint. MSIE requires WebTrust or equivalent audits to
have CAs included in its trusted roots. WebTrust requires that all
public documentation match operational procedures.)
Nah. You are assuming that the users trust that. You
are assuming that this is something that MoFo should
provide. And that MSIE is competing on. And that
WebTrust checks all All these things. So many of these
assumptions ... are so challengeable.
> After the huge accounting
> scandal associated with Enron, it's almost required that the auditor be able
> to have trust revoked from their previously-performed audits, and re-audits
> required when necessary.
We happen to know who the people are who "did" Enron.
They happened to bypass all the supposed checks in
place which were way way stronger than for Internet
certs.
They know what the checks are supposed to be, and they violated their
fiduciary responsibility. Thus, they were held to task with
liability, both fiscal and criminal.
Yep. Standard operating procedures. If you ask people
to be trusted, don't be surprised if they stop being
trusted. "Trust, but verify" old Russian proverb.
MoFo isn't a police organization. That's left to the states (in the
US, and abroad). What's wrong with making law enforcement's task a
little easier, by ensuring that appropriate information is available
for those things that say they're going to use it for financial stuff?
Coz even law enforcement will laugh at you. What, you
expected crooks to provide real identity information to
CAs? Wadayo-nuts-o-summit?
Just because you and a thousand others want the browser
and CAs to guard us poor innocent users against crooks
doesn't mean that is going to happen.
Section 11:
...
I would presume that the 'independent representative' is chosen by
MoFo on basis of trustworthiness -- meaning, it holds a fiduciary
position. (Huh. There's that word again.) The 'independent
representative' could also be a member of MoFo. (Though that might
need to be explicit.) There would be some accountability available,
in any case.
The whole idea is that the accountability is done
by publication of actions and documents. The person
in the hotseat has to justify the actions.
13.
Comment: I think this (chained roots) is a REALLY good policy, and I think
it should be implemented as a requirement ASAP. Thawte used to do this with
its SSL123 certificates, but these certificates have now started to be
issued directly from their root without a chained CA.
Yeah. But nothing much happens there until the CA brand is
put on the chrome. Until CAs have a reason to care, they
won't care.
Like, say, removing their certificate and thus removing the value of
having a cert from that CA? If this document is a listing of
'acceptable criteria' for having the root certificate included, then
if the criteria are no longer met, then the root certificate is not
acceptable anymore, and should be removed.
No, until users learn what a CA is and start to care ;)
As I say, talk of removing a CA is mere bravado, and we
shouldn't take it for more than that until it has been
through a few tests.
14.
Comment: Separate 'SSL-enabled servers' from 'SSL-enabled servers which will
obtain or transfer fiscal information'.
Define fiscal. Be prepared to have that definition tested ;-)
Fiscal Information: Information related to the legal identity of one
or both parties, which may be used for the purposes of
cross-referencing with a third-party database [such as a credit
reporting agency] or for transferring money or property to or from any
of the parties involved.
Well, that latter part works. I personally have done
contracts and transfers of property with psuedonyms,
does that count?
Credit card numbers are fiscal information. Legal names are a
component of fiscal information. (Anonymous cash is explicitly NOT
fiscal information, since it does not include legal identity of the
parties involved.)
By "legal" I suspect you are referring to a legal or
natural person, in a jurisdiction of your choice.
What happens when you are faced with an offshore
company? An LLP? A psuedonym based on an OpenPGP
key? All of which you can get certs for ...
Credit cards can be issued anonymously; there is
at least one country that does this (well, used to).
In contrast, I run a payment system that uses
psuedonyms, which are totally traceable in theory,
but retain privacy based on the use of nyms. These
nyms are good for signing over as much value as they
have available; are they certifiable? Of course,
to the limit of their balance.
There is a massive massive myth that security is
gained through identity. No such case pertains.
Punishment might be meted out through identity,
but that's a big "maybe" and in practice, identities
are bought and sold like any asset. If you want to
do real robust security, then take identity with a
grain of salt. It does play a part, but the part
is about 2 orders of magnitude less important than
you would think.
Please test this definition; I honestly would like to hear different viewpoints.
! The worst and best I can say is that it is
irrelevent. What matters is what you the user
can say in the short term about the person you
are dealing with; not whether you can pass the
person across to the courts to mete out justice,
if such were available.
Comment: It should be explicit in this clause that everything which is
submitted must adhere to the then-current CP, else the request will be
denied.
! So any mistakes means that ... we can drop Verisign?
What this means is, to submit any request for CA inclusion is to take
responsibility for ensuring that the submitter has abided by the terms
of the then-current MoFo Certificate Policy. This means that the CPS
is in the correct format, that auditing has been done (or a request
for an independent competent party has been made), that they're
essentially warranting that they're trying to uphold the letter and
spirit of this policy. Otherwise, it opens up a loophole for
consequential damages ("MoFo didn't include our CA certificate, and so
we lost a lot of certificate sales"), and since there's no clause in
here that states that MoFo won't be liable for it, it could
theoretically be held that it is.
Right. I hope other people realise where this is
going. Is MoFo up to this?
This wouldn't pass the reality test. Once a CA is in,
it's in for a goodly period. They will make mistakes
and they will push the limits.
Verisign made the (in)famous mistake of issuing two code-signing
certificates in Microsoft's name to someone who wasn't authorized.
Yeah. So what? Just an example about how flojo the
system is. It will happen again and again.
They were not removed from MS's root certificate program; there's no
reason why an honest mistake that is caught and disclosed in order to
be acted upon has to result in removal.
However, ongoing and wilfull violations of CPS are a different story.
Ah, ok. So that sounds like a policy statement. Do
you suggest inserting "ongoing and wilfull violations
of CPS" language into the policy? I do not. Too much
verbage, too many shackles.
15.
Comment: Does the Mozilla Foundation even have a formal policy in place for
ajudiciating these types of appeals?
Well spotted! No they do not. The policy is I think
"it goes to the executive committee, sometimes known as
"staff"." Now that's not all bad, there is I gather at
least one person on the exec who has some legal training
and could stand in as arbitrator.
I think this is something that should be ironed out in
time; but I'd suggest it be left until a dispute arises.
That way, there is some experience to show just how much
effort is needed.
Not that this has anything to do with certificate policy at all, but
it's been my experience that these issues WILL come up, sooner or
later -- and there will be one instance where it gets to be such a big
stink that it will threaten the very fabric of trust and goodwill that
holds the project together.
Right. I wonder, the sooner the better. We've
been waiting 10 years now; phishing is sucking
the bloodlife out of user-america, and nobody cares
(wanna buy a 2-factor authenticator? it'll defend
you from phishing for at least 6 months....) We
are well past time for a disaster, because reason
logic and discussion haven't changed anything.
[/rant of person who ran a MUD for almost 6 years]
And you speak as a person who's not had to worry
about the monetary aspects...
16:
Add:
Each approved policy shall be numbered sequentially, in a vM.N manner. If
additional classes of CAs are permitted under the new CP, the M portion
shall increment. If clarifications of existing policy are necessary, the N
portion shall increment.
Rationale: Giving some kind of guidance as to how much scrutiny a
security-conscious person [including security officers] must give any new
revision of the document is probably a good thing. The tricky part is
ensuring that it is adhered to.
I didn't understand this part.
This would be "Mozilla Foundation Certificate Policy v1.0". Any
changes or clarifications within the policy would be "Mozilla
Foundation Certificate Policy v1.1", if they did not allow for CAs
that do not meet the auditing or key protection policies set out in
the three acceptable documents.
If a new class of root certs was allowed, one that did not require
those auditing or key protection policies, or that changed the terms
so that the restrictions on CA certificates embedded were made looser,
then it would be "Mozilla Foundation Certificate Policy v2.0".
OK. So successive policies should be numbered,
so as to identify which ones CAs are signed onto.
Sure.
Thanks! I hope you keep up the comments.
I most certainly intend to... cryptography's been a hobby of mine for
nearly 13 years, and do you have any idea how hard it is to find
anyone to have a decent intellectual discourse about it with? :)
Ha! Have a look at the blog below, you'll wish
you never asked ;)
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
