Ben Bucksch wrote:
Not really, you may want to treat some levels (including self-signed
and plain HTTP,
Considering plain http out of the scope of SSL so...Self-signed is
actually Level 0, which I omitted from the proposal, because it has no
meaning, except if you explicit agree to accept it (similar to accepting
the SSH key ;-)). In this case the browser behaves correctly in my
opinion, so it should be perhaps included in the proposed definition for
the completeness sake.
Eddy, maybe you can add use-cases, both from side of cert applicant
and end-user, and *maybe* even browser. I.e. for what would I get
which cert, or for what would I trust which cert. However, I
nevertheless think that Eddy has a strong point when saying that his
proposal reflects current use, which means that we can implement it
without too much trouble changing CAs around. It should be defined so
that we can later add levels, though, and not only on the top and bottom.
OK, lets try this....from the relying party perspective:
Level 0: Nothing really, except it's your personal site and nobody else
has access to it.
Level 1: Should be used only for password and privacy protection such as
for forums, blogs, web mail, end to end encryption such as smtp servers,
jabber servers, vpn connections, pop3s, imaps, system logon.
Level 2: Can be used for lower volume online shops where transactions
are performed with credit cards, this because of the nature and
protection credit card companies provide to customers for such purchase.
The merchant is also fully aware of these limitations and risk involved
when performing trade via the Internet. Purchases might be limited scope
and amounts, which however depends mostly on the taste of the customer.
Level 3: Can be used for transfer of any kind of critical data including
personal information, banking, health records etc. For signing of
documents and contracts, this level /can/ be sufficient. Can also be
used as a for real world authentication.
Level 4: Signing of contracts and other commitments. This level
substitutes government issued identification documents, such as passport
or identity cards. (This type of certification is many times provided by
a relevant ministry of the country). It implies, that full address and
identification numbers are included in the certificate.
All of the above requires other sanity checks and evaluation by the
relying party of course, but that's not something we control. But it
can't be said enough times so I say it ;-) The subscriber perspective is
covered mostly by the proposal itself.
Ben, does this match your expectations or did you expect something more
in depth or different?
Eddy *explicitly* said the definition of the levels can be changed
based on what Mozilla wants.
Right! It was merely our interpretation and mostly based on our combined
knowledge about the subject.
The core idea of Eddy's proposal was not that, though, but to
introduce the *concept* of different levels of certs, with current
technical standards, and more generically than EV.
EV doesn't solve this problem *at all*. However in the context of the
proposal, EV will be simply integrated without much ado. If there is a
case for EV in its current form, than it will succeed within this
framework.
I think the webtrusty audit includes adhering to their own standards.
And the standards for each level for each CA are public. What changes
is that right now, they make up the levels and can change them at any
time. With Eddy's proposal, they would be bound to *our* definition of
the level (which may or may not conveniently match *current* CA
definition). If they fail to adhere to their own standards, webtrust
and co would probably fail. If they change their published standards,
we should notice.
Two things here:
The flow of adherence to the various levels would be most likely like this:
- The Mozilla CA policy will be extended to include the definition of
the various levels.
- The CAs assign the various verification procedures to the appropriate
level.
- In case of problems one can look up the level and its meaning.
- The CA has to live up to the promise made, e.g. the level it assigned
to the certificate.
- Should the CA have failed to adhere to the promise, do XYZ (which
still has to be defined in any case. Completely missing or irrelevant
from current policy).
However there is another thing which I'd like to mention and suggest
adjustment of the policy and CA inclusion process: As of today, CAs
don't have to make any commitment concerning adherence to the Mozilla CA
policy and doesn't have to sign anything. I think this is "interesting"
to say the least. I suggest to let CAs sign the Mozilla CA and a
statement like: "By requesting a CA certificate to be embedded in
Mozilla software, the CA agrees to adhere to the this policy in full..."
and confirm to have read, understood etc. of the same paper...Something
for the lawyers obviously, but I think it has to be done in some way.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
