Eddy Nigg wrote: > On 10/09/2008 05:33 PM, Ian G: >> The goals of Mozo are written somewhere else, and they only speak >> softly to the issue of security from memory > > I obviously meant the goals of the Mozilla CA Policy and NSS, which > isn't used only by Mozilla (Firefox) but lots of different software. NSS > is a cryptography library.
Sure, just that said goals had better tie up to the general goals of
Mozo as a mothership project, otherwise we have a question mark.
But I'm sure they do, it was the same people involved, IIRC. Small
point.
>> I'd flag as wrong. If there was a goal to allow users to rely on
>> CAs, certificates, etc, then there would be a requirement to tie in
>> the reliance of the Mozilla end-user, and the relying party of the
>> CA, as described in the CPSs and as promoted by the PKI literature
>> as a key person who has to read the key document and enter into this
>> game called reliance.
>>
>> I'd suggest that Mozilla end-users, for the most part, in general,
>> are not relying parties. They may not rely on the certs, or they
>> are likely in for a surprise if they ever want to turn a failure
>> into a recovery.
>>
>> They might *use* the certificates, and then go on to rely in other
>> ways. And, they may go to the CA's website and find out what it
>> takes to become relying parties ... But these are different things.
>>
>
> I don't know in what business you are in,
Weeeelllll.... whatever it is, you'd like it; read on.
> but in my industry digital
> certificates are issued to subscriber so they can provide them to third
> parties for them to rely on the certification, e.g. the third party
> relies on the certificate issued to the subscriber.
OK, as it's your industry, so we can happily refer to Verisign's
Relying Party Agreement:
YOU MUST READ THIS RELYING PARTY AGREEMENT ("AGREEMENT") BEFORE
VALIDATING A VERISIGN CERTIFICATE , USING VERISIGN'S ONLINE
CERTIFICATE STATUS PROTOCOL ("OCSP") SERVICES, ACCESSING OR USING A
VERISIGN OR VERISIGN AFFILIATE DATABASE OF CERTIFICATE REVOCATIONS
OR RELYING ON ANY VERISIGN CERTIFICATE-RELATED INFORMATION
(COLLECTIVELY, "VERISIGN INFORMATION”).
*IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT*,
*DO NOT SUBMIT A QUERY AND DO NOT DOWNLOAD, ACCESS*,
*OR RELY ON ANY VERISIGN INFORMATION*.
IN CONSIDERATION OF YOUR AGREEMENT TO THESE TERMS, YOU ARE ENTITLED
TO USE VERISIGN INFORMATION AS SET FORTH HEREIN.
https://www.verisign.com/repository/rpa.html
Now, curiously, unless we agree to that text, we can't even rely on
that agreement, let along certs, due to its broad commentary, my
emphasis above. That even applies now that the RPA is delivered
under a pretty green cert ;)
So I would suggest -- please by all means possible correct me if
there is another interpretation -- that when a subscriber provides a
Verisign certificate, the user or third party or whoever's pushing
Firefox's buttons today
MUST NOT RELY,
until they have secured permission. Rather explicitly, with a big
solid caps-heavy legal++ scary^2 document, it seems.
And, who does that? Does my interpretation stand [1] ?
Reliance, no. Use, sure.
> Mozilla itself is a relying party
If that was true, there would likely be an agreement between Mozilla
and Verisign (following the above RPA tradition) explicitly giving
Mozilla permission to RELY.
I'm not Mozilla, so I guess we have to ask: Frank, is there any
such agreement that explicitly gives Mozilla permission to RELY?
I don't think there is an agreement, and I think the reason is
historical, not nefarious, these things just weren't thought about
way back when, and it is an acknowledged fact that there hasn't been
so much (if any) review of grandfathered CAs.
If so, here we are at a very important decision point:
Does Mozilla want to be a relying party?
Does it want to impose this on Verisign? Eddy, I guess you are
happy to take on that (having expressed those opinions) .. but what
about the others?
This is rather important because there is an opportunity here for
Mozilla to stamp down a new arrangement. It will improve matters
for users because it will clarify and simply things for them. This
will focus attention on what really matters, security for the users.
It will also help matters for CAs!
> and also makes sure on behalf of its
> users that CAs included with the software adhere to certain criterion.
No argument there.
> Those are defined in the Mozilla CA policy. Users certainly don't have
> to visit the CA websites in order to know that the CA adheres to the set
> requirements of the Mozilla CA Policy (at least).
At least, yes. Right. But they do not have permission to rely.
Not from Mozilla, not from the market-leading CAs. Mozilla itself
has recently gone through an interesting exercise over here:
http://lockshot.wordpress.com/2008/09/17/licensing-proposal-notice-page-screen-shot/
Have a look at those screen shots; looks a lot like "you may USE
but you may not RELY!" to me. (That is my assumption; the authors
were probably not directly thinking about certs. Either way, it's
the only guide I know of, because the policy doesn't address this
question.)
> That's the whole point
> of shipping a set of CA certificates with the library.
Well, that needs revising then. However, I believe it can be done
for the benefit of all (and I really do mean all), so I personally
am not worried about this.
> In order to understand CP/CPS of CAs a certain level of understanding
> about the subject is required, something which Mozilla does on the
> behalf of the user. Most users would fail with such an attempt.
OK. This may or may not be what people think. It's not what the
agreements say. The RPA does not say
"YOU MAY RELY IF YOU FAIL TO UNDERSTAND THIS AGREEMENT......"
so the above statement is maybe an explanation, but it does not
imply anything, and it does not re-interpret the agreements.
> Maybe at Cacert one should find out at their web site about what it
> takes to become a relying party and perhaps one should better use other
> ways for reliance... ;-)
Well, yes! They did that. That's why they discovered the industry
situation above. They constructed an arrangement that works for
them, helps users, and doesn't disadvantage others.
> ...but for most Relying Party Obligations I've seen the software takes
> care of it (e.g. revocation status checking, matching domain/email,
> validity of the certificate, etc.)
Um. Except, the agreements rule over such things, and they say
nothing of the sort, like "we'll take care of it in software..."
OK, I'm not enough of an expert in agency / principle legal theory
to fully understand what the above "take care of it" approach does
when contrasted with the real agreements in place. But there are
clear difficulties there, so I'd suggest that one also goes on the
"revise" list, too.
[snip]
>> "provide a *reasonable* level of assurance that is appropriate
>> to the user's needs, and is matched by the
>> software's security and UI."
>>
>
> I think I could sign on this one. The devil is in the details and the
> definition of the above...
OK, that's something!
iang
[1] Sanity check:
Thawte:
http://www.thawte.com/guides/pdf/cpsrelyingparty.pdf
GetTrust has similar.
Comodo hints that the agreement exists....
OK, we should check EV to see what it says.
Any more for this party?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
