Ah, comments. (Thank you for taking the time to read my
contributions, by the way.)
On 4/17/05, Ian G <[EMAIL PROTECTED]> wrote:
> Kyle Hamilton wrote:
>
> > So, now for the actual changes I would like to suggest about the RC for the
> > CA Certificate Policy:
> >
> > Section 4:
> >
> > Add (first line of criteria):
> >
> > - knowingly and intentionally issue certificates in ways or manners that are
> > not consistent with their CPS.
>
> The trouble with this is that MoFo has to now make a judgment
> on what is consistent with the CPS. Not wishing to get into
> this can of worms, the notion that I preferred was that MoFo
> said "for any reason whatsoever" and this covered it, then
> it was up to the guy in the hot seat to do what he saw fit.
>
> That is, my view is that no amount of words in the policy would
> do much; on the day, it all depends on the circumstances. The
> downside is that any words can also limit actions which will
> carry costs.
>
> This was of course only my view. In the end, a certain amount
> of caveats were added, and they went forward as discussed. I
> am not sure there is much point in adding more.
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?)
> > 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.
(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.)
> > 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?
> > 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.
> > 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.
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.)
> > 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.)
> > 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.)
> > 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.
(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.)
> > 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.
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?
> > Section 11:
> >
> > Modify:
> >
> > [We reserve the right to designate our own representative(s) to act as the
> > competent independent party or parties described above, should that prove to
> > be necessary and appropriate.] The cost of this operation shall be borne
> > equally by the Mozilla Foundation and the CA operator, the CA operator shall
> > pay its share to the Mozilla Foundation, and the Mozilla Foundation shall
> > pay both shares to its chosen representative. In no circumstances shall the
> > CA operator make any payment directly to the Mozilla Foundation's chosen
> > representative, nor shall any items of value be gifted or any preference in
> > future dealings be offered. In any case, the CA operator shall grant audit
> > capability of its CA operations to Mozilla's chosen representative to the
> > full extent determined by the chosen representative, limited to its CA
> > operations and financial dealings thereof, and shall not as a condition of
> > this access require any affirmation of confidentiality or non-disclosure
> > which shall prevent our representative from providing us any information not
> > otherwise protected under law.
> >
> > Rationale: Asking someone to volunteer is one thing (I'll gladly volunteer
> > my time finding bugs, commenting on policies, auditing for compliance, etc),
> > but asking someone to volunteer money for plane trips, hotels, etc is
> > tantamount to demanding that they donate that much money to the Mozilla
> > Foundation. Some people have it, some people don't. The rest of my
> > proposed addition is designed to reduce the chances that the CA operator
> > could influence the performance of the independent competent party... and to
> > ensure that the Mozilla Foundation can actually get the story directly from
> > its chosen representative.
>
> OK, here's where the policy gets subtle. It says that expenses
> should be declared. What that means is that you are free to
> negotiate this with the parties concerned.
>
> But it also means that if any "gifts" are ppaid, then you should
> declare that too. If so declared then the market will judge.
>
> MoFo is a small honest techie organisation. Naive, some would
> say. There is no way known on this planet or the next that it
> will be able to detect ths sort of connivery that you are trying
> to stop in the above paragraphs.
>
> So the policy is subtle. It doesn't try and *stop* bad behaviour
> or force good behaviour. It trys to encourage the disclosure of
> all behaviour. And, then the market will judge. Or not. The
> thing is that it recognises that some things are just beyond its
> power.
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.
> > 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.
> > 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.
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.)
Please test this definition; I honestly would like to hear different viewpoints.
> > 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.
> 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.
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.
> > 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.
[/rant of person who ran a MUD for almost 6 years]
> > 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".
> 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? :)
Cordially,
Kyle A Hamilton
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
