New Baseline Requirements Draft available
Gervase Markham
here:
http://cabforum.org/Baseline_Requirements_Draft_35.pdf
containing a number of changes based on feedback from this group.
The (read-only) spreadsheet tracking the change requests and their
resolution is here:
https://spreadsheets.google.com/ccc?key=0AtEE6hwRJw5cdGNudVN0M1hlSDE2dEs5OG1zVUE5VHc
Please read the new draft and, if the changes you were looking for have
not been made, consult the spreadsheet to see if the request was
recorded and, if so, what the resolution (if any) is.
The end date for discussion is still scheduled for Thursday 26th May. :-|
Thanks,
Gerv
Walter...@rsa.com
Can you check permissions on the spreadsheet? It appears to be inaccessible
as opposed to read-only.
Thanks,
Walter
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Gervase Markham
> Can you check permissions on the spreadsheet? It appears to be inaccessible
> as opposed to read-only.
Yes; my apologies, this is being worked on. Look for an updated link soon.
Gerv
Ben Wilson
https://spreadsheets.google.com/ccc?key=0AtEE6hwRJw5cdGNudVN0M1hlSDE2dEs5OG1
zVUE5VHc&hl=en&authkey=CNvBnfQI#gid=0
But let me know if it doesn't.
Gervase Markham
> The end date for discussion is still scheduled for Thursday 26th May. :-|
The CAB Forum have just agreed on their weekly call to extend this
deadline to the Tuesday 31st May, to give more time for discussion of
the new draft. :-)
Gerv
Gervase Markham
> https://spreadsheets.google.com/ccc?key=0AtEE6hwRJw5cdGNudVN0M1hlSDE2dEs5OG1
> zVUE5VHc&hl=en&authkey=CNvBnfQI#gid=0
This works for me. :-)
Gerv
Walter...@rsa.com
Thanks!
> -----Original Message-----
> From: dev-security-policy-bounces+walter.goulet=rsa...@lists.mozilla.org
> [mailto:dev-security-policy-
> The end date for discussion is still scheduled for Thursday 26th May. :-|
>
Stephen Schultze
"Section 16.3 is undergoing revisions based on current discussions about
auditing and subCA / RA oversight by the Root CA."
Ben Wilson
about the meaning of "CA internal auditing group"? An answer to your
question will likely be handled with interrelated changes throughout all of
section 16, which we currently are working on. So the answer to your
question is that there is no way for you to evaluate it yet because there is
nothing yet to review. Your question arises primarily from the fact that we
committed to releasing interim drafts (rather than hold all comments and
drafts until after the public comment period).
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Stephen Schultze
Sent: Thursday, May 19, 2011 10:47 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: New Baseline Requirements Draft available
How am I to evaluate a "change" that reads like this?
"Section 16.3 is undergoing revisions based on current discussions about
auditing and subCA / RA oversight by the Root CA."
On 5/19/11 12:33 PM, Ben Wilson wrote:
Stephen Schultze
questions 7, 18, 19, 47, and 49 (which relate to questions 11 and 45).
How long before the close of the comment period will text addressing
this fundamental cluster of questions be made available?
Gervase Markham
> How am I to evaluate a "change" that reads like this?
>
> "Section 16.3 is undergoing revisions based on current discussions about
> auditing and subCA / RA oversight by the Root CA."
This means "this particular section is still a work in progress.
Requests to change it have been noted, and are not being ignored or
pushed to a future version, but we don't have a proposal yet."
Rather than wait until all outstanding issues were resolved, we wanted
to provide an interim draft which addressed at least a few of them. This
means that there are still some things being discussed. You've seen my
work on section 16 in this group, and I am due to do another rewrite of it.
Gerv
Gervase Markham
> Well, to be clear, there is not text currently written to respond to my
> questions 7, 18, 19, 47, and 49 (which relate to questions 11 and 45).
>
> How long before the close of the comment period will text addressing
> this fundamental cluster of questions be made available?
I'm not able to say; these provisions are controversial and I'm not part
of the group working on them. :-|
Gerv
Steve Schultze
The deadline has come and gone. As far as I can tell, there's been no
conclusion on any of the issues that folks here raised. Is that true?
Gervase Markham
> The deadline has come and gone. As far as I can tell, there's been no
> conclusion on any of the issues that folks here raised. Is that true?
I'm not quite sure what you mean by "no conclusion on any of the
issues". The status spreadsheet explicitly marks many issues as either
resolved or explicitly deferred to 1.1. There are some which are still
open, and they are being worked on. (The CAB Form had a meeting in Paris
last week to tackle some of the thornier ones.)
Gerv
Steve Schultze
Pardon my lack of specificity. I meant that I don't see evidence of
change in th status of issues listed there. I can't follow every item,
but I know that at least 7, 11, 18, 19, 45, 47, and 49 are still in
limbo. I had hoped that CAB Forum would have some feedback or proposed
resolution during the discussion period, but this did not happen.
Also, the liability cluster of issues (38, 39, and 41) is slated for
future revisions. While I can understand how this could be a
challenging topic, it also seems to be essential to comprehensive
baseline requirements. Issuing a 1.0 without addressing them seems to
risk leaving out a major component of comprehensive requirements.
Gervase Markham
On 16/06/11 14:28, Steve Schultze wrote:
> Pardon my lack of specificity. I meant that I don't see evidence of
> change in th status of issues listed there. I can't follow every item,
> but I know that at least
> 7,
The phrase in question is currently marked as "needs explanation" in the
current draft. The issue has not been resolved.
> 11,
This text has not changed in the current draft; it still means whatever
it means :-) Is it unclear? I have not seen recent discussion centered
on this clause.
> 18,
I recently proposed new text for 13.2.1, which forbade domain validation
delegation except in a couple of non-risky circumstances. An alternative
wording to achieve roughly the same end has been counter-proposed.
Discussion continues.
> 19,
See 18, above.
> 45,
See 11, above.
> 47,
See 18, above.
> 49
The first 3 paras of 11.1 in the current draft all start "The CA or RA".
> Also, the liability cluster of issues (38, 39, and 41) is slated for
> future revisions. While I can understand how this could be a
> challenging topic, it also seems to be essential to comprehensive
> baseline requirements. Issuing a 1.0 without addressing them seems to
> risk leaving out a major component of comprehensive requirements.
The longer we delay issuing BR version 1.0, the longer it is that no-one
is bound to do any of the requirements therein. (And even when CAB Forum
does issue a document, it will be some time before browsers or auditors
take them up.) Don't let the best be the enemy of the better.
Gerv
Ian G
>> Also, the liability cluster of issues (38, 39, and 41) is slated for
>> future revisions. While I can understand how this could be a
>> challenging topic, it also seems to be essential to comprehensive
>> baseline requirements. Issuing a 1.0 without addressing them seems to
>> risk leaving out a major component of comprehensive requirements.
>
> The longer we delay issuing BR version 1.0, the longer it is that no-one
> is bound to do any of the requirements therein. (And even when CAB Forum
> does issue a document, it will be some time before browsers or auditors
> take them up.) Don't let the best be the enemy of the better.
Sure, but that is the view of the CAs. For them, this is a good
document, and making it better doesn't get them much benefit. Better
for the CAs in CABForum to agree not to waste time in marginal improvement.
Maybe it's even good for the vendors, I don't know.
However for the relying parties and the users, BR is not (yet?) a good
document. It doesn't fully explain the liabilities (which is what the
RPs and users want and need) and it includes a long long list of
expensive barriers, which make the competitors more and more
concentrated [0] with hand-wavy mechanisms that aren't shown to lead to
a better result. Which the users and RPs neither want nor need.
For the relying party, we need to know (a) who is a relying party (RP),
and (b) what the relying party has of benefit when the cert fails.
Neither of these questions are answered, they are both carefully walked
around. The document is carefully written to allow enough ambiguity
there to fit multiple opposing and contradictory viewpoints.
The answers are fairly simple. (a) RPs are signatories to the relying
party agreement with each CA. But BR is written to give an impression
that the user-public are RPAs. This is false.
Or if it is not false, please explictly say in the document that the RP
is the user-public, and make it so for all CAs [1]. Because when it
gets to court, the average CA will be working on the RP-signs-RPA
definition, which will not be useful nor germane to Mozilla.
(b) is nothing. BR 17.1 states that, but in a manner that favours the
CAs. By saying "May Disclaim" it indicates that the RPs and users are
on their own, because they will have to go on a voyage of discovery to
figure out that all CAs dislaim. Instead, it would be nice to be clear
to users/RPs, and insist that the CAs clearly and openly state the
disclaimer and liability position, rather than bury them in complicated
PKI documentation structures.
(It would be far better if BR were to grasp the nettle and simply state
that all CAs issuing BR-level product were to state full disclaimers to
extent of law, and zero liability. Mandated. Then, this would leave
the CAs to increase from zero. Aka compete. Rather than hide behind
the fig leaf. Aka cartelise. But that's too much to ask.)
In delivering something of value to the RPs and the users (different
folks) we have to start by being entirely clear as to what the current
situation is. Only then can we start thinking about a better situation.
For the users and RPs, it isn't about being an enemy of the good, it's
about being an enemy of the expensive and useless and deceptive. Start
by clarifying what the situation is.
Another way of putting this is that without any representation [2] by
users in the authoring of the document, this is the result.
iang
[0] E.g., audit is now more expensive. There is now a risk analysis
which is a serious cost, and I'll bet most don't understand that one.
Business of RAs and enterprise CAs is getting more costly...
[1] I wouldn't necessarily advise this course. It's too complicated to
change the current legal definition without a reason, and the switch is
far to complicated to be understood.
[2] One could propose that Browsers will look after the interests of
users. I would dispute that; Section 17.2 is their benefit, vendors
have their interest met, and that's pretty clear if one understands the
legal sense of those two sections. This is good, so far. But beyond
that, vendors have obviously accepted 17.1 without complaint, so looking
after users is off the agenda.
Kyle Hamilton
>
> The answers are fairly simple. (a) RPs are signatories to the relying party
> agreement with each CA. But BR is written to give an impression that the
> user-public are RPAs. This is false.
I believe that in this case, since the industry is not effectively
policing itself, the answer will be found in the court system:
"Mozilla mandates these things so that people can use them materially
to inform their decisions." If they're incapable of being used as
such under disclaimer, then Mozilla must stop mandating them (or,
arguably, even exposing them to the user).
> Another way of putting this is that without any representation [2] by users
> in the authoring of the document, this is the result.
Users, protection-paying businesses and non-business site owners,
non-browser application vendors, state...
This entire situation is worthy of being called SNAFUBAR.
If Mozilla can really be held accountable by the users, why hasn't
Mozilla ever listened to the users who know what their needs are? Oh
right, because the users don't actually pay anything for the software,
so it's just lip service.
Get a grip, Mozilla. You're eyeball-deep and sinking.
-Kyle H
Gervase Markham
> [0] E.g., audit is now more expensive. There is now a risk analysis
> which is a serious cost, and I'll bet most don't understand that one.
> Business of RAs and enterprise CAs is getting more costly...
I remember you saying something about this in one of your bits of
feedback, but it was accompanied by a whole lot of verbiage and I
frankly didn't take it in.
By contrast, another bit of feedback you gave was effectively something
like:
"Section X is incompatible with the Mozilla policies, as well as being
anti-competitive. Need I say more?"
- short and to the point. With regard to the latter, I have been arguing
our case for change in the CAB Forum ever since. The former, nothing got
done.
A lesson in communication? :-)
Gerv
Steve Schultze
> "The current draft" below refers to draft 36.
>
> On 16/06/11 14:28, Steve Schultze wrote:
>> Pardon my lack of specificity. I meant that I don't see evidence of
>> change in th status of issues listed there. I can't follow every item,
>> but I know that at least
>
>> 7,
>
> The phrase in question is currently marked as "needs explanation" in the
> current draft. The issue has not been resolved.
>
>> 11,
>
> This text has not changed in the current draft; it still means whatever
> it means :-) Is it unclear? I have not seen recent discussion centered
> on this clause.
I think it's unclear. Kathleen does. What do you think it means?
>> 18,
>
> I recently proposed new text for 13.2.1, which forbade domain validation
> delegation except in a couple of non-risky circumstances. An alternative
> wording to achieve roughly the same end has been counter-proposed.
> Discussion continues.
Would you like to share that wording for feedback here? The alternate
wording?
>> 19,
>
> See 18, above.
>
>> 45,
>
> See 11, above.
>
>> 47,
>
> See 18, above.
>
>> 49
>
> The first 3 paras of 11.1 in the current draft all start "The CA or RA".
In that case, doesn't the current draft permit RAs to perform domain
validation?
11.1:
"The CA or RA MUST confirm that, as of the date the Certificate was
issued, the Applicant either had the right 21 to use, or had control of,
the Fully-Qualified Domain Name(s) and/or IP address(es) listed in the
Certificate..."
In any case, there remains the question of SubCA disclosure mentioned in
issue 49 (as well as 45).
>> Also, the liability cluster of issues (38, 39, and 41) is slated for
>> future revisions. While I can understand how this could be a
>> challenging topic, it also seems to be essential to comprehensive
>> baseline requirements. Issuing a 1.0 without addressing them seems to
>> risk leaving out a major component of comprehensive requirements.
>
> The longer we delay issuing BR version 1.0, the longer it is that no-one
> is bound to do any of the requirements therein. (And even when CAB Forum
> does issue a document, it will be some time before browsers or auditors
> take them up.) Don't let the best be the enemy of the better.
The less buy-in from the community, the less likely the BR are to be
adopted. If there are major problems with 1.0, its not going to be used
anyway.
Ian G
> On 27/06/11 15:54, Ian G wrote:
>> which is a serious cost, and I'll bet most don't understand that one.
>> Business of RAs and enterprise CAs is getting more costly...
>
> feedback, but it was accompanied by a whole lot of verbiage and I
> frankly didn't take it in.
>
> By contrast, another bit of feedback you gave was effectively something
> like:
>
> "Section X is incompatible with the Mozilla policies, as well as being
> anti-competitive. Need I say more?"
>
> - short and to the point.
I really feel embarrassed by being told to be rude more often :)
> With regard to the latter, I have been arguing
> our case for change in the CAB Forum ever since. The former, nothing got
> done.
Outstanding!
> A lesson in communication? :-)
Lol... whatever it is, we all out here in user-land feel we're talking
to a black hole, so we'll take any scrap of feedback we can get :)
In Salute, Let's Try The Short Approach:
Liability is the sand on which CAs are built. You need to fix the
users' liability to zero in BR and fix it solid. Read any CPS for
evidence: liability equals zero.
iang
Gervase Markham
>> This text has not changed in the current draft; it still means whatever
>> it means :-) Is it unclear? I have not seen recent discussion centered
>> on this clause.
>
> I think it's unclear. Kathleen does. What do you think it means?
For reference, this is section 8.4, which says:
"8.4 Trust model
The CA MUST disclose the identities of all issuers of Certificates that
identify the CA as the Subject."
I don't have trouble understanding that as an English sentence. You are
going to need to be more specific. Is it ambiguous? If so, how? What are
the possible interpretations? Which one would you like?
>> I recently proposed new text for 13.2.1, which forbade domain validation
>> delegation except in a couple of non-risky circumstances. An alternative
>> wording to achieve roughly the same end has been counter-proposed.
>> Discussion continues.
>
> Would you like to share that wording for feedback here? The alternate
> wording?
My wording was an addition to 13.2.1 which made it say:
(original)
The CA MAY delegate the performance of all, or any part, of these
Requirements to an Affiliate, RA, Enterprise RA, or subcontractor,
provided that the process as a whole fulfills all of the requirements of
Section 11. Affiliates, RAs, Enterprise RAs, and subcontractors MUST
comply with the qualification requirements of Section 13.1, as
applicable to their function within the Certificate [055] Management
Process. Prior to delegating functions to an RA or sub CA that is not
operated by the CA, the CA MUST review, evaluate and determine that the
entity’s practice statement complies with these Requirements.
(addition)
Notwithstanding the above, the CA may not delegate the domain control
validation process required by section 11.1 unless either:
a) the CA confirms the authenticity of each Certificate Request sent to
it by the delegated entity using an out-of-band mechanism involving at
least one human being; or
b) the delegated entity is audited on all relevant points under the same
Audit Criteria as the CA.
I don't have the author's permission to share the alternate wording.
>> The first 3 paras of 11.1 in the current draft all start "The CA or RA".
>
> In that case, doesn't the current draft permit RAs to perform domain
> validation?
See above.
Gerv
Gervase Markham
> I really feel embarrassed by being told to be rude more often :)
"Short and to the point" != rude. :-)
> In Salute, Let's Try The Short Approach:
>
> Liability is the sand on which CAs are built. You need to fix the
> users' liability to zero in BR and fix it solid. Read any CPS for
> evidence: liability equals zero.
This is not as helpful. The good example I quoted had an implicit change
request - "remove section X, or fix it to make it compatible with
Mozilla policy section Y". This summary has no such change request.
Concrete proposals please! :-)
Gerv
Steve Schultze
> On 29/06/11 20:39, Steve Schultze wrote:
>>> This text has not changed in the current draft; it still means whatever
>>> it means :-) Is it unclear? I have not seen recent discussion centered
>>> on this clause.
>>
>> I think it's unclear. Kathleen does. What do you think it means?
>
> For reference, this is section 8.4, which says:
>
> "8.4 Trust model
>
> The CA MUST disclose the identities of all issuers of Certificates that
> identify the CA as the Subject."
>
> I don't have trouble understanding that as an English sentence. You are
> going to need to be more specific. Is it ambiguous? If so, how? What are
> the possible interpretations? Which one would you like?
I can parse it too. The question is what the purpose is, and whether
there are scenarios that Kathleen or I couldn't think of. Is the
purpose to force the CA to disclose it's own cross-certifiers? Is there
more?
How would a CA confirm domain control authenticity of a Certificate
Request using a (completely) out-of-band mechanism? Isn't the question
at hand explicitly domain control, which is something that can only be
verified by using DNS? Even if you're checking WHOIS data, it's not
completely OOB. And in any case, if the CA has to confirm the
authenticity of the request, then it hasn't really delegated validation.
I don't see the point of a).
Must the delegated entity meet the other non-audit CA criteria contained
in the BR? Liability, etc. If the RA must meet all the CA requirements,
then I don't see a reason for stating it as an exception to CA
validation because they are acting as a CA.
It seems to me that a modification saying simply the first part of your
proposal would suffice, and be far clearer:
"Notwithstanding the above, the CA may not delegate the domain control
validation process required by section 11.1."
> I don't have the author's permission to share the alternate wording.
>
>>> The first 3 paras of 11.1 in the current draft all start "The CA or RA".
>>
>> In that case, doesn't the current draft permit RAs to perform domain
>> validation?
>
> See above.
Apart from any proposed changes to section 13, the current draft of 11
permits RAs to perform domain validation.
Kathleen Wilson
> On 6/30/11 6:30 AM, Gervase Markham wrote:
>> On 29/06/11 20:39, Steve Schultze wrote:
>>>> This text has not changed in the current draft; it still means whatever
>>>> it means :-) Is it unclear? I have not seen recent discussion centered
>>>> on this clause.
>>>
>>> I think it's unclear. Kathleen does. What do you think it means?
>>
>> For reference, this is section 8.4, which says:
>>
>> "8.4 Trust model
>>
>> The CA MUST disclose the identities of all issuers of Certificates that
>> identify the CA as the Subject."
>>
>> I don't have trouble understanding that as an English sentence. You are
>> going to need to be more specific. Is it ambiguous? If so, how? What are
>> the possible interpretations? Which one would you like?
>
> I can parse it too. The question is what the purpose is, and whether
> there are scenarios that Kathleen or I couldn't think of. Is the purpose
> to force the CA to disclose it's own cross-certifiers? Is there more?
>
I was told that it applied to cross-signed certs only. So I suppose it
means that the CA must disclose the identities of any CA with which it
has cross-signed certs.
Perhaps the requirement is more clear to others than it is to me?
Kathleen
Ian G
> On 29/06/11 22:18, Ian G wrote:
>
"Short and to the point" implies complete understanding and agreement.
I strongly recommend the book at the end of this:
http://iang.org/negotiation/ , which only costs about $10. Really cheap
for the value in communications.
>> In Salute, Let's Try The Short Approach:
>>
>> Liability is the sand on which CAs are built. You need to fix the
>> users' liability to zero in BR and fix it solid. Read any CPS for
>> evidence: liability equals zero.
>
> This is not as helpful. The good example I quoted had an implicit change
> request - "remove section X, or fix it to make it compatible with
> Mozilla policy section Y". This summary has no such change request.
Let's make it explicit:
17.1: Liability MUST be fully disclaimed.
> Concrete proposals please! :-)
LOL... let's pour:
=============================
17.1 Agreement to Disclaim Liability to Subscribers and Relying Parties
Certificates issued under these requirements are a zero-liability
product. The CA *MUST disclaim all liability* to the customer to the
extent possible under law [1]. In addition, the CA SHOULD seek to limit
its liability to zero by methods that are customary and legal in its
jurisdiction.
CAs MUST NOT make any representation, marketing statement, variation in
contract or claim that confuses or hides the basic principle that
certificates issued under these requirements are a zero-liability product.
17.2 Liability to users who are not Relying Parties
The CA MUST state that users who have not entered into the CA's Relying
Party Agreement are not entitled to rely on the certificates, but may
use the certificates as facilitated by application software [2].
17.3 Application Software Suppliers ... [3]
==============================
That concrete sets fast, let me know when you want more ;)
iang
PS: Once we're agreed on the basic thrust, we'll need some more details
such as in these footnotes.
[1] The CA must have a readily-identifiable agreement for liability for
certificates issued under these requirements [1]. The agreement MAY be
joint or MAY be separate for the customers (Subscribers, and Relying
Parties). The agreement(s) must be written in clear and plain language,
must be available on the website, and must be notified to software vendors.
[2] This statement MUST be done clearly and plainly. CAs MAY make this
statement in CP/CPS or by an open license agreement for that express
purpose. The statement MUST disclaim all liability to the extent
possible under law. The CA SHOULD use customary and legal methods to
limit that liability. The CA SHOULD state that the rights of the user
are less than that of a Relying Party, and clearly signal the method by
which each user may enter into a Relying Party Agreement.
[3] (Then, re-align vendors' claims with CAs' claims....)
Kyle Hamilton
>
> For reference, this is section 8.4, which says:
>
> "8.4 Trust model
>
> The CA MUST disclose the identities of all issuers of Certificates that
> identify the CA as the Subject."
>
> I don't have trouble understanding that as an English sentence. You are
> going to need to be more specific. Is it ambiguous? If so, how? What are
> the possible interpretations? Which one would you like?
IIRC, this was to handle the situation where the CA issued its own
certificate and there was a cross-certificate for that CA's public key
as well. (It was related to a CA which had not yet received approval
for inclusion in Mozilla, but was cross-certified by another CA which
already had.)
I think it should be changed, though, because the CA may have multiple
root keys. My suggestion:
"The CA MUST disclose the identities of all issuers of Certificates
that identify the CA's subjectPublicKeyInfo."
-Kyle H
Gervase Markham
> I can parse it too. The question is what the purpose is, and whether
> there are scenarios that Kathleen or I couldn't think of. Is the
> purpose to force the CA to disclose it's own cross-certifiers? Is there
> more?
I'm not sure what its purpose is :-) My point is that unless someone
explains to me what the possible interpretations are, and why it's
ambiguous, and which interpretation they like, and what the text should
say, I can hardly go and argue for a change :-)
>> b) the delegated entity is audited on all relevant points under the same
>> Audit Criteria as the CA.
>
> How would a CA confirm domain control authenticity of a Certificate
> Request using a (completely) out-of-band mechanism?
The issue we are trying to prevent here is the idea that if an RA is
compromised, the attacker can push a button and get a cert (the "Italian
scenario"). If domain control is not contracted out, this can't happen.
If the CA and the RA get on the phone together and the RA says "yes, I
did just send you a request for a cert for www.foo.com"), this can't
happen. Either should be permitted.
IOW, it's not the domain control which is checked by the OOB mechanism,
it's the validity of the signing request coming from the RA.
> "Notwithstanding the above, the CA may not delegate the domain control
> validation process required by section 11.1."
Except that some CAs want to delegate it, and have what I judge to be
sufficient safeguards surrounding that (i.e. an out of band request
authenticity confirmation step).
> Apart from any proposed changes to section 13, the current draft of 11
> permits RAs to perform domain validation.
Then we'd need to make it clear that section 13 governed.
Gerv
Gervase Markham
> "The CA MUST disclose the identities of all issuers of Certificates
> that identify the CA's subjectPublicKeyInfo."
Now that, I _can't_ parse as English :-( How does a person (an issuer)
"identify" a particular field (subjectPublicKeyInfo) in a certificate?
Gerv
Steve Schultze
> On 30/06/11 15:50, Steve Schultze wrote:
>> I can parse it too. The question is what the purpose is, and whether
>> there are scenarios that Kathleen or I couldn't think of. Is the
>> purpose to force the CA to disclose it's own cross-certifiers? Is there
>> more?
>
> I'm not sure what its purpose is :-) My point is that unless someone
> explains to me what the possible interpretations are, and why it's
> ambiguous, and which interpretation they like, and what the text should
> say, I can hardly go and argue for a change :-)
What we asked for in the first place was for a clarification of the
purpose. If you don't know what its purpose is, please go ask them and
report back.
>>> b) the delegated entity is audited on all relevant points under the same
>>> Audit Criteria as the CA.
>>
>> How would a CA confirm domain control authenticity of a Certificate
>> Request using a (completely) out-of-band mechanism?
>
> The issue we are trying to prevent here is the idea that if an RA is
> compromised, the attacker can push a button and get a cert (the "Italian
> scenario"). If domain control is not contracted out, this can't happen.
> If the CA and the RA get on the phone together and the RA says "yes, I
> did just send you a request for a cert for www.foo.com"), this can't
> happen. Either should be permitted.
>
> IOW, it's not the domain control which is checked by the OOB mechanism,
> it's the validity of the signing request coming from the RA.
Right, and the problem with this is that the regime needs to solve both.
We have seen both failure modes in the wild. Your suggestion creates a
loophole where non-audited, non-disclosed entities gain the operational
ability to issue certs (unless perhaps if issue 7 is resolved by
requiring RA audits, and some disclosure requirement is added).
Incidentally, another inconsistency in the draft is that 13.2.2 says,
"For RAs and sub CAs that are not operated by the CA, the CA MUST review
each RA’s or sub CA’s independent audit report prior to processing
certificate requests from the RA or issuing a certificate to the sub
CA." But nowhere does the draft require an audit to exist.
>> "Notwithstanding the above, the CA may not delegate the domain control
>> validation process required by section 11.1."
>
> Except that some CAs want to delegate it, and have what I judge to be
> sufficient safeguards surrounding that (i.e. an out of band request
> authenticity confirmation step).
>
>> Apart from any proposed changes to section 13, the current draft of 11
>> permits RAs to perform domain validation.
>
> Then we'd need to make it clear that section 13 governed.
The more straightforward thing would be to remove all "or RA" references
from 11.1 because they have no place being there.
If the BR continue to blur the lines between audited and disclosed CA
privileges and those of third-parties, they will likely conflict with
the Mozilla Cert Policy revisions currently underway.
Kyle Hamilton
that bind Issuer credentials, either directly or indirectly, to its
public key.
-Kyle H
On Fri, Jul 1, 2011 at 2:26 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 30/06/11 20:43, Kyle Hamilton wrote:
>> "The CA MUST disclose the identities of all issuers of Certificates
>> that identify the CA's subjectPublicKeyInfo."
>
> Now that, I _can't_ parse as English :-( How does a person (an issuer)
> "identify" a particular field (subjectPublicKeyInfo) in a certificate?
>
> Gerv
>
>
Kyle Hamilton
>
> 17.1: Liability MUST be fully disclaimed.
>
How about...
17.1: "Liability to Subscribers, Relying Parties, and particularly end
users must be explicitly disclaimed, but waiver of this disclaimer may
be provided for a premium."
If you want CAs to offer better service, then maybe they'd like to cap
their liability at a higher amount.
Whatever is agreed to, though, the software has to call to the user's
attention. "This CA says this about the holder of this key, but
unless you have a separate agreement there is no legal recourse if
what this CA says is wrong!"
-Kyle H
Ian G
> On Thu, Jun 30, 2011 at 11:50 AM, Ian G<ia...@iang.org> wrote:
>>
>> 17.1: Liability MUST be fully disclaimed.
>>
>
> How about...
>
> 17.1: "Liability to Subscribers, Relying Parties, and particularly end
> users must be explicitly disclaimed, but waiver of this disclaimer may
> be provided for a premium."
>
> If you want CAs to offer better service, then maybe they'd like to cap
> their liability at a higher amount.
>
> Whatever is agreed to, though, the software has to call to the user's
> attention. "This CA says this about the holder of this key,
Yes. This is what the CA says about the certificate overall. Zero
liability.
> but
> unless you have a separate agreement there is no legal recourse if
> what this CA says is wrong!"
Secondly, could the CA say something above and beyond this statement of
fully disclaiming all liabilities to zero?
This opens a can of worms. I wrestled with this as well, and I
recognise that everyone will also wrestle with it.
I have decided *NO*. To my knowledge, these things hold:
(a) no CA offers positive liability to any vendor's user [0].
(b) no CA should offer any non-zero liability to users [1].
(c) the product is labelled BASELINE.
If those above are accepted, then the answer is clear: make it so.
Zero liability should be mandated in BR.
Rather than bolstering (a), (b), (c) with rants, I'll ask some questions:
What possible reason could there be for avoiding a clear
and simple statement of the truth of zero liability to users?
The only possible reason I can think of is deception -- that the maker
of such a statement wishes to promote a marketing perception that this
product is something that it is not. As that is deception (assuming (a)
above), I am not clear why anyone would support it?
Further, another question:
What happens when CA-Trent wants to offer an
effective and positive liability to users?
In the case where it was unclear that BASELINE was a zero liability
value-by-use product, then there would be little marketing advantage in
offering a real positive liability product: users won't be able to see
the difference between Trent-CA's effective liability of non-zero, and
the deceptive but zero-liability of all other CAs doing BASELINE.
Promoting the deception of positive liabilities in BR ensures that we
will never see real positive liabilities.
Therefore, ban it. And let it emerge in some other place/product, if
anyone can figure out how to avoid (b) above [1].
iang
[0] That I know of. To qualify that slightly, some of the QC CAs will
offer positive nominal liabilities, but effective is probably still
zero. Also, QC isn't baseline, and isn't SSL.
[1] See that "An Open Audit" discussion for more details on why a CA
should not say any different. For example, while EVG suggests positive
nominal limits in its text, the *effective liability is almost certainly
still zero* for all circumstances of relevance.
Kyle Hamilton
>
> I have decided *NO*. To my knowledge, these things hold:
>
> (a) no CA offers positive liability to any vendor's user [0].
> (b) no CA should offer any non-zero liability to users [1].
> (c) the product is labelled BASELINE.
I never suggested liability to any vendor's user (i.e., non-Relying
Party). The CA must be able to sell Relying Party agreements as
something more than zero-cost products. (By definition, a Relying
Party is someone who conforms to the CA's requirements to be able to
legitimately verify the CA's signature, which might as well include
'pay some cash'.)
Once a vendor's software user enters into an agreement, that user
stops being a "user" for purposes of this discussion, and starts being
a Relying Party.
> If those above are accepted, then the answer is clear: make it so. Zero
> liability should be mandated in BR.
>
> Rather than bolstering (a), (b), (c) with rants, I'll ask some questions:
>
> What possible reason could there be for avoiding a clear
> and simple statement of the truth of zero liability to users?
How is "there is no legal recourse if what the CA says is wrong"
anything other than a statement of zero liability?
If the user has not entered into a separate Relying Party agreement,
there is zero liability. If the user has entered into the no-cost
Relying Party agreement, there is zero liability. If the user has
paid for the privilege of having a warranty (c.f. warranty-extension
contracts of consumer electronics chains), then the user is not a user
but a Relying Party.
How is it a bad thing if the CAs can actually make money from their
relying parties, rather than solely the people who are forced to pay
the user-interface protection racket? They must be able to sell
warranties.
-Kyle H
Ian G
> On Sun, Jul 3, 2011 at 8:06 PM, Ian G<ia...@iang.org> wrote:
>>
>> I have decided *NO*. To my knowledge, these things hold:
>>
>> (a) no CA offers positive liability to any vendor's user [0].
>> (b) no CA should offer any non-zero liability to users [1].
>> (c) the product is labelled BASELINE.
>
> I never suggested liability to any vendor's user (i.e., non-Relying
> Party). The CA must be able to sell Relying Party agreements as
> something more than zero-cost products.
Well, in principle I don't disagree with what you are trying to achieve.
But in practice, I don't think we can support that statement:
"The CA must be able to sell Relying Party agreements
as something more than zero-cost products."
RPAs are free, as a matter of today practicality. (Subscriber
Agreements are non-zero cost, generally.) I'm not sure whether we can
ever see a world where RPAs should be paid for, and current marketing
structure pretty much rules it out.
So, I am quite comfortable in suggesting that RPAs should remain free,
*at least for the Baseline Requirements product*. If we think they are
a good idea, perhaps suggest it for the EVG.
> (By definition, a Relying
> Party is someone who conforms to the CA's requirements to be able to
> legitimately verify the CA's signature,
Yes.
> which might as well include
> 'pay some cash'.)
are you really suggesting this, or is this confused with Subscriber
Agreement?
> Once a vendor's software user enters into an agreement, that user
> stops being a "user" for purposes of this discussion, and starts being
> a Relying Party.
Yes, exactly.
>> If those above are accepted, then the answer is clear: make it so. Zero
>> liability should be mandated in BR.
>>
>> Rather than bolstering (a), (b), (c) with rants, I'll ask some questions:
>>
>> What possible reason could there be for avoiding a clear
>> and simple statement of the truth of zero liability to users?
>
> How is "there is no legal recourse if what the CA says is wrong"
> anything other than a statement of zero liability?
No different, as far as I can see.
> If the user has not entered into a separate Relying Party agreement,
> there is zero liability. If the user has entered into the no-cost
> Relying Party agreement, there is zero liability. If the user has
> paid for the privilege of having a warranty (c.f. warranty-extension
> contracts of consumer electronics chains), then the user is not a user
> but a Relying Party.
Correct, all.
> How is it a bad thing if the CAs can actually make money from their
> relying parties, rather than solely the people who are forced to pay
> the user-interface protection racket? They must be able to sell
> warranties.
Ah, so you are entertaining the possibility from a sort of "RP gets the
value, RP should pay for it" approach.
From a business perspective, it won't work, IMHO. There are many
reasons for this, I'll try and list them.
1. All RPs have been so long stuck in the zero-liability track that it
is hard to change that now. RPs are going to ask -- why pay for it now,
does it change anything?
2. I'd argue that Baseline Requirements is not the place to change it,
if only because of that word: Baseline.
3. The certs so delivered are going to be more or less transparent
anyway. Mozilla's browser is going to show them as white background.
Mozilla is going to show BR as approximately the same level as HTTP. If
anything, RPs should try and get EVG to be the "warrantied" product.
4. If we look at the entire picture of due diligence over some
certificate-inspired transaction in real-money-space, it still doesn't
make a lot of sense to stick a warranty on *the certificate*. All the
user knows is that the name is correct; a false or true name is such a
small proportion of the overall transaction space that to purport a
warranty on that is going to leave a bad taste in victim's mouth.
5. Even if the CA comprehensively stuffed up, every CA says that the
user must do their own due diligence. Which means that any damages (any
warranty) is limited to small amounts, before it becomes clear that the
user "relied inappropriately". E.g., when grandma loses her house on a
sale backed by a cert, she failed to do proper conveyencing. So she's
outa luck, because of inappropriate reliance.
etc etc, all IMHO, iang.
Gervase Markham
> Therefore, ban it. And let it emerge in some other place/product, if
> anyone can figure out how to avoid (b) above [1].
The Baseline Requirements are baseline. You don't stop complying with
them when you produce a product which exceeds them. A ban would
effectively prevent such a product from existing.
Gerv
Ian G
> On 04/07/11 04:06, Ian G wrote:
>> anyone can figure out how to avoid (b) above [1].
>
> them when you produce a product which exceeds them. A ban would
> effectively prevent such a product from existing.
Easy enough to fix in the extension document:
1. This document incorporates all elements of BR except 17.1 which
is replaced in xx.y of the present document.
Just as an aside, is there an intention that EVG is to be rewritten as
an extention of BR?
iang
Steve Schultze
> RPAs are free, as a matter of today practicality. (Subscriber Agreements
> are non-zero cost, generally.) I'm not sure whether we can ever see a
> world where RPAs should be paid for, and current marketing structure
> pretty much rules it out.
>
> So, I am quite comfortable in suggesting that RPAs should remain free,
> *at least for the Baseline Requirements product*. If we think they are a
> good idea, perhaps suggest it for the EVG.
I'd like to point out that RPAs are meaningless today from a legal
perspective. Nobody has ever put forth any plausible argument for how
RPs might be privy to such an agreement, and as such there's just no
plausible way they'd hold up in court. Thus, any disclaiming done there
is likely to be irrelevant.
If, on the other hand, there was a complete disclaimer of liability
built into the BR, *maybe* this would be sufficiently seen as a standard
that it would hold up in court. The question is whether or not we want
this to be the case. I can see both sides to the argument.
Moudrick M. Dadashov
> On 7/4/11 4:55 AM, Ian G wrote:
>> are non-zero cost, generally.) I'm not sure whether we can ever see a
>> world where RPAs should be paid for, and current marketing structure
>> pretty much rules it out.
>>
>> So, I am quite comfortable in suggesting that RPAs should remain free,
>> *at least for the Baseline Requirements product*. If we think they are a
>> good idea, perhaps suggest it for the EVG.
>
> perspective. Nobody has ever put forth any plausible argument for how
> RPs might be privy to such an agreement, and as such there's just no
> plausible way they'd hold up in court. Thus, any disclaiming done
> there is likely to be irrelevant.
>
is regulated by a Civil code and there are real cases where CA's failure
to fulfill it's obligation to *public* has been properly "nominated".
But you are right it's meaningless where national legislation doesn't
not know who those CAs are. So we must distinguish two different legal
environments the one you folks are discussing now and another one that
has it's own enforcement mechanism.
> If, on the other hand, there was a complete disclaimer of liability
> built into the BR, *maybe* this would be sufficiently seen as a
> standard that it would hold up in court. The question is whether or
> not we want this to be the case. I can see both sides to the argument.
regulated it really doesn't matter what BR or any other similar
"standard"say.
M.D.
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
--
M.D.
Cell: +370-699-26662
Ian G
> On 7/4/11 4:55 AM, Ian G wrote:
>> are non-zero cost, generally.) I'm not sure whether we can ever see a
>> world where RPAs should be paid for, and current marketing structure
>> pretty much rules it out.
>>
>> So, I am quite comfortable in suggesting that RPAs should remain free,
>> *at least for the Baseline Requirements product*. If we think they are a
>> good idea, perhaps suggest it for the EVG.
>
> perspective. Nobody has ever put forth any plausible argument for how
> RPs might be privy to such an agreement, and as such there's just no
> plausible way they'd hold up in court. Thus, any disclaiming done there
> is likely to be irrelevant.
I'd love to be the attorney collecting fees on the other side of that
case :)
But, we might be able to avoid a discussion on the different
interpretations of RP/user/etc, if we can agree on what we are trying to
achieve -- disambiguation of the liability situation:
> If, on the other hand, there was a complete disclaimer of liability
> built into the BR, *maybe* this would be sufficiently seen as a standard
> that it would hold up in court.
Support for the standard that liability is disclaimed is indeed what I'd
seek to disambiguate the situation.
How it's done is less relevant than that it is done. BR would be fine
for it, BR is to be (an element of) the contract between CAs and vendors.
(I doubt we could put an actual disclaimer in. These things vary too
much from place to place. But we can put the spirit in.)
> The question is whether or not we want
> this to be the case. I can see both sides to the argument.
Sure.
iang
Eddy Nigg
> But, we might be able to avoid a discussion on the different
> interpretations of RP/user/etc, if we can agree on what we are trying
> to achieve -- disambiguation of the liability situation:
>
I think that neither yourself nor Mozilla is in the position to do that.
Either way. And discussing this subject in a public forum is
unfortunately not really possible for some participants.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kyle Hamilton
>
> Well, in principle I don't disagree with what you are trying to achieve.
> But in practice, I don't think we can support that statement:
>
> "The CA must be able to sell Relying Party agreements
> as something more than zero-cost products."
>
> are non-zero cost, generally.) I'm not sure whether we can ever see a world
> where RPAs should be paid for, and current marketing structure pretty much
> rules it out.
I have no intention of preventing the current no-cost RPAs from being
entered into. I just want to ensure that the option of allowing the
CAs to provide a service (higher liability limits) in exchange for
income is available.
Since I think the CAs aren't doing the right thing today, I think it's
insane to mandate that everyone be forced to stay at the bottom.
Hypothetical business model:
A Credit Reporting Agency (CRA) decides to get into the certification
business. To do so, it decides that it's going to restrict access to
its currently-valid short-validity-interval intermediate CA's public
key to those who have current subscriptions. Upon that CA's notAfter
plus 120 minutes, it chooses to publish not only the public key but
also the private key, such that old certifications are worthless
unless the recipient has a trusted timestamp over the certified data
within that same CA's validity period.
CRA has no interest in permitting zero-cost RPAs, as its subscribers
are not the same entities who are being certified. The entities who
are being certified are the ones it has fair credit reporting
responsibilities to, while the entities who are subscribing need that
information for something useful (such as "deciding whether to extend
credit").
Mandating that a business with this model be forced to permit
zero-liability reliance is like cutting a flower off from its root.
It looks pretty, but if the flower's cut before it has a chance to
pollinate anything else -- much less before it can go to seed -- it's
wasted energy and effort.
> So, I am quite comfortable in suggesting that RPAs should remain free, *at
> least for the Baseline Requirements product*. If we think they are a good
> idea, perhaps suggest it for the EVG.
You wish to make the EVG a function of the BR, and more importantly to
mandate that every CA provide RPAs for free. This means that
everyone's product must start at the bottom with no way to say "once
you catch up to us, we'll adhere to the requirements you have there --
but we're not going to let our intermediate CAs be known until our
service is paid for."
Here's a question:
CRA would want its root included in publicly-available software so
that its certifications can be evaluated at the precise moment of
validity plus a bit of slop. Because it doesn't publish its
currently-valid intermediate CA except to people who obtain
certifications of their credit report, it doesn't want to have any
value at all to non-subscribers (not merely zero liability, but zero
utility), it exposes formerly-closed keys. Would this be permissible
under your interpretation of the BR?
In summary, the current players aren't the only people involved. Do
you contemplate that the current CA members of the CABF will never be
joined by any others with different business models?
If EVG are a function of the BR, would EVG have to start at zero
liability as well?
-Kyle H
Kyle Hamilton
>
> I think that neither yourself nor Mozilla is in the position to do that.
> Either way. And discussing this subject in a public forum is unfortunately
> not really possible for some participants.
Can the list of participants who cannot discuss this subject in a
public forum be disclosed? Or is that confidential information as
well?
The problem with not discussing this subject in a public forum is that
Mozilla's participation is a public forum. Without the public
discussion, Mozilla and more importantly its users are just (if you'll
pardon the expression) spitting into the wind.
Frankly, if there are CAs who aren't able to discuss this openly, I
want full disclosure: I want to be able to talk with their
subscribers (certified entities) and explain why I don't trust the
service(s) those entities chose to certify their identity.
dev.security.policy and the CABF have been all about restricting the
capacity for a legitimate market to exist.
-Kyle H
Eddy Nigg
> Can the list of participants who cannot discuss this subject in a
> public forum be disclosed?
Not sure if there is a list, but representatives of CAs most likely are
not able to comment. Take myself as an example.
> Frankly, if there are CAs who aren't able to discuss this openly, I
> want full disclosure: I want to be able to talk with their
> subscribers (certified entities) and explain why I don't trust the
> service(s) those entities chose to certify their identity.
Feel free to do that, except that probably no CA will be willingly
disclose all their subscribers.
> dev.security.policy and the CABF have been all about restricting the
> capacity for a legitimate market to exist.
???
Gervase Markham
> Easy enough to fix in the extension document:
>
> 1. This document incorporates all elements of BR except 17.1 which
> is replaced in xx.y of the present document.
Except that many CAs today issue using what is effectively an undefined,
CA-specific superset of the BRs - in that they do more than they are
required to. This seems to me to be a good thing, and banning it would
be somewhat counterproductive.
> Just as an aside, is there an intention that EVG is to be rewritten as
> an extention of BR?
No-one has jumped up and down with a burning passion to do it, but it
might happen I guess :-)
Gerv
Ian G
> On 04/07/11 11:33, Ian G wrote:
>>
>> 1. This document incorporates all elements of BR except 17.1 which
>> is replaced in xx.y of the present document.
>
> CA-specific superset of the BRs - in that they do more than they are
> required to.
Yes, you're talking about product differentiation whereas I am talking
about deception [0]. Different ends of the same line.
> This seems to me to be a good thing, and banning it would
> be somewhat counterproductive.
No, this is an error of general to specific.
Letting the CAs offer an undefined, CA-specific superset is fine, a good
thing. That's called product differentiation, competition and all that.
Being undefined about liability, when we know the number is zero,
however is another thing: deception, which is one of the three elements
of fraud.
Which is a current problem with the industry, and a contributing factor
to deadly embrace. You can't get out of the deadly embrace until the
product is revealed fairly.
Recall a recent comment words to effect that "we (meaning mozilla) won't
have the power to change it, and nobody wants to talk about it out
loud..." That's evidence of deadly embrace. That's because no CA can
admit to it, and therefore, no CA can be associated with changing it [1].
In the sense that we would want BR to improve things, getting rid of the
deceptive belief that some sort of liability cover exists for baseline
certs would be a good thing.
Then, it would be reasonable to offer a superset - BR plus liability.
Until then, not.
>> Just as an aside, is there an intention that EVG is to be rewritten as
>> an extention of BR?
>
> No-one has jumped up and down with a burning passion to do it, but it
> might happen I guess :-)
EVG would be a fine place to discuss a positive liability, because it is
a premium product.
iang
[0] Do any of the CAs claim a non-zero liability limit? Do any of them
mean it? I think the answer is No, for at least every base product I've
seen. There might be some issue with the QC CAs which may have mandated
limits, but in general, BR and QC shouldn't intersect (QC is for
individuals as client-certs in general).
[1] Which also means that CABForum can't do it, being biased towards
CAs. Commercial vendors don't care (it doesn't hurt them, now that they
have their disclosure in the BR). Only Mozilla & KDE care, because only
they answer to users above their own interests.
Steve Schultze
> On 7/4/2011 6:51 PM, Steve Schultze wrote:
>> I'd like to point out that RPAs are meaningless today from a legal
>> perspective. Nobody has ever put forth any plausible argument for how
>> RPs might be privy to such an agreement, and as such there's just no
>> plausible way they'd hold up in court. Thus, any disclaiming done
>> there is likely to be irrelevant.
>>
> Sorry, they are not meaningless. Imagine when the accountability of CA
> is regulated by a Civil code and there are real cases where CA's failure
> to fulfill it's obligation to *public* has been properly "nominated".
> But you are right it's meaningless where national legislation doesn't
> not know who those CAs are. So we must distinguish two different legal
> environments the one you folks are discussing now and another one that
> has it's own enforcement mechanism.
RPAs that are written by CAs and "offered" unilaterally by being posted
at some unknown URL or included in some X.509 field that no user ever
sees are meaningless.
Perhaps there is a jurisdiction that says, as a matter of law, that such
RPAs must be posted at some known location and are considered valid.
That would be an exception. I have yet to have anybody show me a
real-world example, but I'd be very interested to see one.
Steve Schultze
>> If, on the other hand, there was a complete disclaimer of liability
>> built into the BR, *maybe* this would be sufficiently seen as a standard
>> that it would hold up in court.
>
> Support for the standard that liability is disclaimed is indeed what I'd
> seek to disambiguate the situation.
As I understand it, your argument is that because relying parties are
unlikely to be able to differentiate between different levels of
liability, it would be best to fix liability at one level across the
board for all certs of the same type. Your further argument is that as
long as some CAs disclaim all liability, we need to require that of all
CAs in order to achieve uniform liability.
I would prefer that there be some baseline of non-zero liability, but I
can appreciate how this is nearly impossible for DV certs.
As such, I am largely persuaded by your argument. I'm not sure that
putting such a standard into the BR would necessarily accomplish what
you wish in a court of law, but it would move it in the right direction
and perhaps eliminate some ambiguity.
I would further argue that RPAs be prohibited, because they are entirely
non-enforceable and only generate confusion.
Moudrick M. Dadashov
On 7/12/2011 5:20 PM, Steve Schultze wrote:
> On 7/4/11 2:43 PM, Moudrick M. Dadashov wrote:
>> On 7/4/2011 6:51 PM, Steve Schultze wrote:
>>> I'd like to point out that RPAs are meaningless today from a legal
>>> perspective. Nobody has ever put forth any plausible argument for how
>>> RPs might be privy to such an agreement, and as such there's just no
>>> plausible way they'd hold up in court. Thus, any disclaiming done
>>> there is likely to be irrelevant.
>>>
>> Sorry, they are not meaningless. Imagine when the accountability of CA
>> is regulated by a Civil code and there are real cases where CA's failure
>> to fulfill it's obligation to *public* has been properly "nominated".
>> But you are right it's meaningless where national legislation doesn't
>> not know who those CAs are. So we must distinguish two different legal
>> environments the one you folks are discussing now and another one that
>> has it's own enforcement mechanism.
>
> RPAs that are written by CAs and "offered" unilaterally by being
> posted at some unknown URL or included in some X.509 field that no
> user ever sees are meaningless.
>
> Perhaps there is a jurisdiction that says, as a matter of law, that
> such RPAs must be posted at some known location and are considered
> valid. That would be an exception. I have yet to have anybody show me
> a real-world example, but I'd be very interested to see one.
just take any CA operating under EU/National el. signature legislation,
should be what you are looking for. CP/CPS/RPA are a mandatory part of
relationship regulation between service providers and service consumers.
Thanks,
M.D.
cell: +370-699-26662
Stephen Schultze
Although I have heard others say this, I have yet to see this be true.
Let's start at the top, though. The EC Directive 1999/93/EC is, I
believe the relevant directive:
http://europa.eu/legislation_summaries/information_society/other_policies/l24118_en.htm
===
Article 6
Liability
1. As a minimum, Member States shall ensure that by
issuing a certificate as a qualified certificate to the public or by
guaranteeing such a certificate to the public a certification-
service-provider is liable for damage caused to any entity or
legal or natural person who reasonably relies on that certificate
[...]
3. Member States shall ensure that a certification-service-provider may
indicate in a qualified certificate limitations on the use of that
certificate, provided that the limitations are recognisable to third
parties.
[...]
5. The provisions of paragraphs 1 to 4 shall be without prejudice to
Council Directive 93/13/EEC of 5 April 1993 on unfair terms in consumer
contracts (1).
(1) OJ L 95, 21.4.1993, p. 29.
===
The first thing to notice is that the liability provisions apply only to
"qualified certificates." What is a qualified certificate? Well...
===
ANNEX I
Requirements for qualified certificates
Qualified certificates must contain:
(a) an indication that the certificate is issued as a qualified
certificate;
(b) the identification of the certification-service-provider and the
State in which it is established;
(c) the name of the signatory or a pseudonym, which shall be identified
as such;
(d) provision for a specific attribute of the signatory to be included
if relevant, depending on the purpose for which the
certificate is intended;
(e) signature-verification data which correspond to signature-creation
data under the control of the signatory;
(f) an indication of the beginning and end of the period of validity of
the certificate;
(g) the identity code of the certificate;
(h) the advanced electronic signature of the
certification-service-provider issuing it;
(i) limitations on the scope of use of the certificate, if applicable; and
(j) limits on the value of transactions for which the certificate can be
used, if applicable.
===
Most notably, DV certificates do not typically contain "the name of the
signatory or a pseudonym." They often don't include "limits on the
value of transactions for which the certificate can be used" either. I
believe that qualified certificates are much more akin to EV certs. So,
the directive and all the derivative national legislation is likely moot
in the case of DV.
But let's assume it *is* relevant. We then encounter Article 6, Section
3, which notes that the limits on liability must be "recognisable to
third parties." We now have something similar to a typical offer
requirement, which must be recognizable in order to accept. So, it
seems, that even qualified certificates do not necessarily trigger some
assumed knowledge of the limitations, and the attendant acceptance.
To add to this, Section 5 makes clear that apart from anything in this
directive, the normal standards for fairness in consumer contracts
apply. I don't know the details of Directive 93/13/EEC, but I imagine
that it doesn't consider unilateral posting of liability limitations
without notice to the user to be fair (and I somehow doubt that a link
to such limitations in the body of the certificate would be held to be
fair either).
So, it seems, the ability of CAs to disclaim liability via an RPA is
quite similar in both types of legal regimes you describe. Or am I
wrong? Are there specific national statutes that apply?
You noted earlier that, "there are real cases where CA's failure to
fulfill it's obligation to *public* has been properly "nominated"." I
believe this (and I'd like to know the actual case citations), but that
doesn't necessarily speak to the CA's ability to alter that obligation
via something like an RPA.
This area is fairly new to me, so I would encourage corrections and
pointers.
Steve
Ian G
> On 7/4/11 2:43 PM, Moudrick M. Dadashov wrote:
>>> I'd like to point out that RPAs are meaningless today from a legal
>>> perspective. Nobody has ever put forth any plausible argument for how
>>> RPs might be privy to such an agreement,
Persons need to be privy to some agreement. Otherwise they are bound by
whatever else was offered. What are such persons privy to, if they are
not privy to the RPA?
>>> and as such there's just no
>>> plausible way they'd hold up in court. Thus, any disclaiming done
>>> there is likely to be irrelevant.
>>>
>> Sorry, they are not meaningless. Imagine when the accountability of CA
>> is regulated by a Civil code and there are real cases where CA's failure
>> to fulfill it's obligation to *public* has been properly "nominated".
>> But you are right it's meaningless where national legislation doesn't
>> not know who those CAs are. So we must distinguish two different legal
>> environments the one you folks are discussing now and another one that
>> has it's own enforcement mechanism.
>
> RPAs that are written by CAs and "offered" unilaterally by being posted
> at some unknown URL or included in some X.509 field that no user ever
> sees are meaningless.
>
> Perhaps there is a jurisdiction that says, as a matter of law, that such
> RPAs must be posted at some known location and are considered valid.
> That would be an exception. I have yet to have anybody show me a
> real-world example, but I'd be very interested to see one.
It's just straightforward contract law. The judge says "show me the
contract" and the CA does. The other person doesn't. It's turtles all
the way down from there...
The problem is being looked at the wrong way. The legal theory is that
the presence of RPAs makes everything else meaningless. And if you want
to dispute that in court, you are welcome to do so, but going up against
a real contract is a loser's game.
iang
PS: not commenting on the "civil code" side, that's a different story.
Ian G
> On 7/4/11 4:18 PM, Ian G wrote:
>>> built into the BR, *maybe* this would be sufficiently seen as a standard
>>> that it would hold up in court.
>>
>> Support for the standard that liability is disclaimed is indeed what I'd
>> seek to disambiguate the situation.
>
> unlikely to be able to differentiate between different levels of
> liability, it would be best to fix liability at one level across the
> board for all certs of the same type. Your further argument is that as
> long as some CAs disclaim all liability, we need to require that of all
> CAs in order to achieve uniform liability.
My argument is more like:
1. effective liability for all CAs is zero. (Or show me the counter case.)
2. the body public falsely believes there is some liability, something.
3. CAs cannot state 1. because they sell certs to people in group 2.
4. CAs cannot offer a better liability product because there is no way
to distinguish it. The body public believes it has it already.
5. The only way to offer a better product therefore is to unwind 2. by
(for example) setting the liability for baseline product to zero in
contract (BR).
> I would prefer that there be some baseline of non-zero liability, but I
> can appreciate how this is nearly impossible for DV certs.
Well, the argument is easy if we're talking about mozilla users.
How many mozilla users are there? How much expected liability can we
have from each? Multiply those two numbers out ... You just went
bankrupt. QED, effective liability is zero.
Or make it more concrete: Facebook uses a cert from a CA which results
in all Facebook user details being breached. 500,000,000 multiplied by
average cost of data breach per person. Calculate, run to bankrupcy court.
The only number that makes that formula work is zero. QED.
> As such, I am largely persuaded by your argument. I'm not sure that
> putting such a standard into the BR would necessarily accomplish what
> you wish in a court of law, but it would move it in the right direction
> and perhaps eliminate some ambiguity.
In a court of law, a user will push up some sort of "industry standard"
defence that says that the liability for the cert should be high, based
on what they read or where told, etc.
If the CA shows BR as an industry standard document, and it agrees with
their RPA, this defence is demolished.
(It matters not whether the CA uses an RPA or their CPS, being the old
way. They could happily show their CPS, there is at least one CA we
know of that puts the disclaimer in the CPS and doesn't have an RPA. No
big issue here.)
> I would further argue that RPAs be prohibited, because they are entirely
> non-enforceable and only generate confusion.
:) Well, that's how I feel about CPSs, which are written with
mindlessly endless legions of technobabble. The law tends to cut
through that sort of crap and reach for the contract. Which is the RPA.
Simple, short.
I'm curious, what do you think is an enforceable document for a user?
If you were a user and you were going to court, what would you present?
iang
Steve Schultze
An end-user wouldn't likely sue a CA directly. Instead, they'd sue a
subscriber, with whom they have a more direct connection. As noted in
my co-authored article from last year:
http://www.freedom-to-tinker.com/blog/sroosa/flawed-legal-architecture-certificate-authority-trust-model
===
The end-user's assent to these standard documents is generally neither
obtained nor sought. There appears to be no occasion when an end-user
clicks his or her assent to the relying party agreement, the CPS, or the
subscriber agreement. As far as the end-user is concerned, these
documents do not exist.
The absence of assent by the end-user places the Web site operator that
is a "subscriber" to the CA's SSL certificates in a difficult position,
as Web site operators are actively encouraging end-users to rely heavily
on SSL encrypted communications, while entering into contracts with CAs
that seek to minimize, if not eliminate, the end-user's right to rely on
the authentication processes on which SSL communications depend. A
review of the published decisional law fails to reveal any court
decision that speaks directly to the issue of end-user rights relative
to the legal documentation associated with the CA Trust Model. As a
result, the legal architecture on which the model rests is untested.
==
Subscribers often make promises to relying parties, which are at least
as enforceable as the rest of their terms of service
The RPA has no effect on this relationship... it deals with the CA (not
the Subscriber) and it's entirely unenforceable.
The Subscriber would in turn seek to transfer that liability onto the
CA, but Subscriber Agreements uniformly include indemnification. EV is
the exception.
So perhaps the best way of putting it is that any RP suit against a CA
would likely be dismissed immediately as naming the wrong plaintiff. It
never reaches analysis of whether the RPA stands up or not. However,
the ongoing existence of RPAs causes confusion for everybody, including
Subscribers who may incorrectly believe that it insulates them from
liability.
Steve Schultze
> On 13/07/11 12:25 AM, Steve Schultze wrote:
>> I would prefer that there be some baseline of non-zero liability, but I
>> can appreciate how this is nearly impossible for DV certs.
>
> Well, the argument is easy if we're talking about mozilla users.
>
> How many mozilla users are there? How much expected liability can we
> have from each? Multiply those two numbers out ... You just went
> bankrupt. QED, effective liability is zero.
>
> Or make it more concrete: Facebook uses a cert from a CA which results
> in all Facebook user details being breached. 500,000,000 multiplied by
> average cost of data breach per person. Calculate, run to bankrupcy court.
>
> The only number that makes that formula work is zero. QED.
Liability exists for at least two reasons:
1. compensation
2. deterrence
Full compensation on a large scale is impossible, as you point out.
However, intermediate options exist, including capped total liability,
which is precisely what EV does.
Deterrence works in either case. Companies certainly don't like to file
for bankruptcy, nor do they like to make large but not fatal payouts.
Thus, they are motivated to improve their practices to avoid these outcomes.
>> As such, I am largely persuaded by your argument. I'm not sure that
>> putting such a standard into the BR would necessarily accomplish what
>> you wish in a court of law, but it would move it in the right direction
>> and perhaps eliminate some ambiguity.
>
> In a court of law, a user will push up some sort of "industry standard"
> defence that says that the liability for the cert should be high, based
> on what they read or where told, etc.
>
> If the CA shows BR as an industry standard document, and it agrees with
> their RPA, this defence is demolished.
>
> (It matters not whether the CA uses an RPA or their CPS, being the old
> way. They could happily show their CPS, there is at least one CA we know
> of that puts the disclaimer in the CPS and doesn't have an RPA. No big
> issue here.)
>
>> I would further argue that RPAs be prohibited, because they are entirely
>> non-enforceable and only generate confusion.
>
>
> :) Well, that's how I feel about CPSs, which are written with mindlessly
> endless legions of technobabble. The law tends to cut through that sort
> of crap and reach for the contract. Which is the RPA. Simple, short.
A contract which has no hope of passing the privity smell test.
> I'm curious, what do you think is an enforceable document for a user? If
> you were a user and you were going to court, what would you present?
As noted in my previous message, I'd sue the Subscriber (under their ToS
or other direct statements to me) to get at the CA.
Eddy Nigg
I find your conversation with Ian rather amusing - if I assume
correctly, neither you nor Ian are either legal professionals nor
running a CA. Why don't you get some serious consulting with specialists
in this field and some law professionals before tossing out statements
over statements?
Nothing I've seen in this conversation is based on any evidence, serious
research or legal opinion which could form a basis for any serious
evaluation (without taking any position of anything said here). Further
the situation(s) may differ quite a bit between various countries, laws
and jurisdictions - just for a starter.
Anyway, I'm tempted to through in some additional statements in respect
to the number zero (to keep in line with the conversation's subject),
but I probably shouldn't... :-)
Stephen Schultze
> I find your conversation with Ian rather amusing - if I assume
> correctly, neither you nor Ian are either legal professionals nor
> running a CA. Why don't you get some serious consulting with specialists
> in this field and some law professionals before tossing out statements
> over statements?
>
> Nothing I've seen in this conversation is based on any evidence, serious
> research or legal opinion which could form a basis for any serious
> evaluation (without taking any position of anything said here). Further
> the situation(s) may differ quite a bit between various countries, laws
> and jurisdictions - just for a starter.
>
> Anyway, I'm tempted to through in some additional statements in respect
> to the number zero (to keep in line with the conversation's subject),
> but I probably shouldn't... :-)
Yes, you got huffy when I first released my article too. I think it's
because it points out things that you find uncomfortable.
My co-author is a well-qualified legal professional who litigates on
computer security matters... but you don't have to be a legal
professional to understand the basic legal principles we are discussing
here.
So, until you see fit to make an actual argument rather than just
inaccurate ad hominim missives, there's really nothing to respond to.
Eddy Nigg
>
> Yes, you got huffy when I first released my article too. I think it's
> because it points out things that you find uncomfortable.
Not really, rather that I can't advise either way. Perhaps if one day
I'm not working for a CA anymore, I could probably say a lot more.
>
> So, until you see fit to make an actual argument rather than just
> inaccurate ad hominim missives, there's really nothing to respond to.
>
Well, I think even with our all basic understandings, you are missing
the point without substantial backup by legal consultants/professionals.
Just consider that even legal professionals would have a hard time to
provide a correct assessment and it would very much depend on which side
of the divide they'd stand (respectively represent).
Therefore I believe the discussion is treading water and I'm biting my
tongue in order not to offend anybody here. But don't expect that there
is any particular value, even if you repeat the same statements hundred
times, it doesn't makes it correct. That's what I'm trying to say.
Stephen Schultze
>> So, until you see fit to make an actual argument rather than just
>> inaccurate ad hominim missives, there's really nothing to respond to.
>>
>
> Well, I think even with our all basic understandings, you are missing
> the point without substantial backup by legal consultants/professionals.
This is false.
In addition to the qualified legal professional who was my co-author, I
believe that you will discover that all other reasonable legal
professionals will come to a similar conclusion. See, for example,
Stephen Mason's book "Electronic Signatures in Law" (1847660517), which
does an international comparison of law related to electronic signatures
and concludes that:
- RPAs are unlikely to satisfy offer and acceptance, or even "deemed
acceptance" (Chapter 6, Sec 28)
- RPAs are unlikely to satisfy consideration (Chapter 6, Sec, 46)
- RPAs are unlikely to satisfy privity (Chapter 5, Sec 48)
> Just consider that even legal professionals would have a hard time to
> provide a correct assessment and it would very much depend on which side
> of the divide they'd stand (respectively represent).
You have pointed to no "legal professionals" who espouse this theory,
nor provided your own theory of why this would be true.
> Therefore I believe the discussion is treading water and I'm biting my
> tongue in order not to offend anybody here.
And I believe that your "critique" (if it can be called that) is
baseless and completely unjustified.
Jeremy Rowley
co-author's conclusion. I know of many others who would also disagree.
IMO, the enforceability of an RPA would likely follow the same analysis as
the enforceability of a browser-wrap agreement. In short:
1) RPAs are deemed accepted by the use of the certificate, similar to
browser-wrap agreements.
2) The consideration is the use of the certificate, similar to the
consideration found in browser-wrap agreements.
3) Privity exists because the RP is using the service, similar to other
browser-wrap agreements.
The big glaring problem that always arises with these debates is that the
opponents of RPAs can't seem to pin down a specific cause of action against
the service provider. Obviously, from their point of view, it can't be a
contract claim (since they claim privity doesn't exist). So which tort
claim is applicable? Negligence requires a legally-recognized duty, breach,
causation, and damages.
Plus, if each certificate includes a link to the relevant RPA and the
browsers fail to display or relay this link to the end-user (both of which
are true), then your main issue with enforceability is with the browser, not
the CA.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Stephen Schultze
Sent: Wednesday, July 13, 2011 12:27 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 7/13/11 2:04 PM, Eddy Nigg wrote:
>> So, until you see fit to make an actual argument rather than just
>> inaccurate ad hominim missives, there's really nothing to respond to.
>>
>
> Well, I think even with our all basic understandings, you are missing
> the point without substantial backup by legal consultants/professionals.
This is false.
In addition to the qualified legal professional who was my co-author, I
believe that you will discover that all other reasonable legal
professionals will come to a similar conclusion. See, for example,
Stephen Mason's book "Electronic Signatures in Law" (1847660517), which
does an international comparison of law related to electronic signatures
and concludes that:
- RPAs are unlikely to satisfy offer and acceptance, or even "deemed
acceptance" (Chapter 6, Sec 28)
- RPAs are unlikely to satisfy consideration (Chapter 6, Sec, 46)
- RPAs are unlikely to satisfy privity (Chapter 5, Sec 48)
> Just consider that even legal professionals would have a hard time to
> provide a correct assessment and it would very much depend on which side
> of the divide they'd stand (respectively represent).
You have pointed to no "legal professionals" who espouse this theory,
nor provided your own theory of why this would be true.
> Therefore I believe the discussion is treading water and I'm biting my
> tongue in order not to offend anybody here.
And I believe that your "critique" (if it can be called that) is
baseless and completely unjustified.
_______________________________________________
Eddy Nigg
>
> In addition to the qualified legal professional who was my co-author,
> I believe that you will discover that all other reasonable legal
> professionals will come to a similar conclusion.
Stephen, I'm sorry for the misunderstanding, but I haven't voiced an
opinion here about your article (I hardly remember what it was about). I
was commenting on the ongoing discussion here on this list.
>
> You have pointed to no "legal professionals" who espouse this theory,
> nor provided your own theory of why this would be true.
I explicitly stated that I'm not voicing an opinion either way. And I
don't want to.
>
> And I believe that your "critique" (if it can be called that) is
> baseless and completely unjustified.
>
Look, I believe that Mozilla shouldn't voice an opinion either, lest set
any requirements in this respect about this subject. Remember that
Mozilla could be a party on either side at some point.
Just consider Mozilla would head the battle cry of years from Ian and
adopt such a stupid requirement, and the next day a court throws it out
of the window at the first opportunity and press for charges and
compensation... Guess who the affected party would sue next.
Seriously, if you think Mozilla should mess with it, let their lawyers
make a recommendation if, how, when it should do that. Just my advise,
do what you want.
(I'm not against anybody voicing an opinion, but I'm against making
statements that appear to look as if they are the golden truth by
repeating them over and over again.)
Stephen Schultze
> IMO, the enforceability of an RPA would likely follow the same analysis as
> the enforceability of a browser-wrap agreement. In short:
> 1) RPAs are deemed accepted by the use of the certificate, similar to
> browser-wrap agreements.
In that case, you may wish to refresh your memory on Specht v. Netscape,
the touchstone browserwrap case (which, incidentally, Stephen Mason
discusses in his analysis). For your convenience, here is the Wikipedia
article:
http://en.wikipedia.org/wiki/Specht_v._Netscape_Communications_Corp.
There is simply no reasonable interpretation of current certificate
usage that wouldn't fall prey to the same problem of Specht, namely "a
reasonably prudent Internet user in circumstances such as these would
not have known or learned of the existence of the license terms".
Without an offer, the necessary acceptance, consideration, and privity
cannot exist. Can you explain how it is otherwise?
I'd also recommend a great primer on the reach and accessibility of such
software licenses by a friend of mine, entitled "The Software License
Unveiled":
http://www.amazon.com/Software-License-Unveiled-Legislation-Controls/dp/0195341872
Jeremy Rowley
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Stephen Schultze
Sent: Wednesday, July 13, 2011 3:01 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 7/13/11 4:32 PM, Jeremy Rowley wrote:
> IMO, the enforceability of an RPA would likely follow the same analysis as
> the enforceability of a browser-wrap agreement. In short:
> 1) RPAs are deemed accepted by the use of the certificate, similar to
> browser-wrap agreements.
In that case, you may wish to refresh your memory on Specht v. Netscape,
the touchstone browserwrap case (which, incidentally, Stephen Mason
discusses in his analysis). For your convenience, here is the Wikipedia
article:
http://en.wikipedia.org/wiki/Specht_v._Netscape_Communications_Corp.
There is simply no reasonable interpretation of current certificate
usage that wouldn't fall prey to the same problem of Specht, namely "a
reasonably prudent Internet user in circumstances such as these would
not have known or learned of the existence of the license terms".
Without an offer, the necessary acceptance, consideration, and privity
cannot exist. Can you explain how it is otherwise?
I'd also recommend a great primer on the reach and accessibility of such
software licenses by a friend of mine, entitled "The Software License
Unveiled":
http://www.amazon.com/Software-License-Unveiled-Legislation-Controls/dp/0195
341872
_______________________________________________
Ian G
> I'm a reasonable legal professional, and I disagree with you and your
> co-author's conclusion. I know of many others who would also disagree.
>
> the enforceability of a browser-wrap agreement. In short:
> 1) RPAs are deemed accepted by the use of the certificate, similar to
> browser-wrap agreements.
> consideration found in browser-wrap agreements.
> 3) Privity exists because the RP is using the service, similar to other
> browser-wrap agreements.
Nod. I'd join with this.
But I think it matters less than people think. That's because the
result is the same whichever way it goes:
> The big glaring problem that always arises with these debates is that the
> opponents of RPAs can't seem to pin down a specific cause of action against
> the service provider. Obviously, from their point of view, it can't be a
> contract claim (since they claim privity doesn't exist). So which tort
> claim is applicable? Negligence requires a legally-recognized duty, breach,
> causation, and damages.
>
> Plus, if each certificate includes a link to the relevant RPA and the
> browsers fail to display or relay this link to the end-user (both of which
> are true), then your main issue with enforceability is with the browser, not
> the CA.
Who now have in place a BR disclaimer. Mozilla recently introduced
their own browser-wrapped licence which also disclaims. And of course,
others have had this for a while.
*So the end effect is the same*. Whichever legal path the challenge
goes, based on positive solid merits, the users get nothing.
Hence my oft-repeated claim that liability to CAs is zero for all users.
And BR should say that, so we can sweep away the decade and a half of
nonsense. And get on with improving that situation within its real
paramaters.
iang
> Jeremy
>
> -----Original Message-----
> From:
> dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
> [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
> .org] On Behalf Of Stephen Schultze
> Sent: Wednesday, July 13, 2011 12:27 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
>
> On 7/13/11 2:04 PM, Eddy Nigg wrote:
>>> So, until you see fit to make an actual argument rather than just
>>> inaccurate ad hominim missives, there's really nothing to respond to.
>>>
>>
>> Well, I think even with our all basic understandings, you are missing
>> the point without substantial backup by legal consultants/professionals.
>
> This is false.
>
> In addition to the qualified legal professional who was my co-author, I
> believe that you will discover that all other reasonable legal
> professionals will come to a similar conclusion. See, for example,
> Stephen Mason's book "Electronic Signatures in Law" (1847660517), which
> does an international comparison of law related to electronic signatures
> and concludes that:
>
> - RPAs are unlikely to satisfy offer and acceptance, or even "deemed
> acceptance" (Chapter 6, Sec 28)
> - RPAs are unlikely to satisfy consideration (Chapter 6, Sec, 46)
> - RPAs are unlikely to satisfy privity (Chapter 5, Sec 48)
>
>> Just consider that even legal professionals would have a hard time to
>> provide a correct assessment and it would very much depend on which side
>> of the divide they'd stand (respectively represent).
>
> You have pointed to no "legal professionals" who espouse this theory,
> nor provided your own theory of why this would be true.
>
>> Therefore I believe the discussion is treading water and I'm biting my
>> tongue in order not to offend anybody here.
>
> And I believe that your "critique" (if it can be called that) is
> baseless and completely unjustified.
>
Jeremy Rowley
UNLESS the service provider has contractually agreed otherwise with either
the customer or the RP (and that contract is backed by adequate insurance).
Jeremy
iang
>>> So, until you see fit to make an actual argument rather than just
>>> inaccurate ad hominim missives, there's really nothing to respond to.
>>>
>>
>> Well, I think even with our all basic understandings, you are missing
>> the point without substantial backup by legal consultants/professionals.
>
> This is false.
>
> In addition to the qualified legal professional who was my co-author, I
> believe that you will discover that all other reasonable legal
> professionals will come to a similar conclusion. See, for example,
> Stephen Mason's book "Electronic Signatures in Law" (1847660517), which
> does an international comparison of law related to electronic signatures
> and concludes that:
>
> - RPAs are unlikely to satisfy offer and acceptance, or even "deemed
> acceptance" (Chapter 6, Sec 28)
> - RPAs are unlikely to satisfy consideration (Chapter 6, Sec, 46)
> - RPAs are unlikely to satisfy privity (Chapter 5, Sec 48)
>
>> Just consider that even legal professionals would have a hard time to
>> provide a correct assessment and it would very much depend on which side
>> of the divide they'd stand (respectively represent).
>
> You have pointed to no "legal professionals" who espouse this theory,
> nor provided your own theory of why this would be true.
>
>> Therefore I believe the discussion is treading water and I'm biting my
>> tongue in order not to offend anybody here.
>
> And I believe that your "critique" (if it can be called that) is
> baseless and completely unjustified.
>
Stephen Schultze
> I remember Specht v. Netscape. There have been cases since then.
That is true. There have even been many cases that cited Specht v.
Netscape. However, there haven't been any that challenged the central
finding that I cited.
Just for fun I took a minute to look through all Westlaw negative
treatment of Specht. There are 10 cases, and none of them challenge
this premise.
Of course, there may be some obscure case that you have in your back
pocket. I and the rest of the cyberlaw scholarly community would love
to see it.
Stephen Schultze
> On 07/13/2011 09:27 PM, From Stephen Schultze:
>>
>> In addition to the qualified legal professional who was my co-author,
>> I believe that you will discover that all other reasonable legal
>> professionals will come to a similar conclusion.
>
> Stephen, I'm sorry for the misunderstanding, but I haven't voiced an
> opinion here about your article (I hardly remember what it was about). I
> was commenting on the ongoing discussion here on this list.
You are being duplicitous. You quoted the part of the discussion that
contained solely a lengthy quote of my article.
>> You have pointed to no "legal professionals" who espouse this theory,
>> nor provided your own theory of why this would be true.
>
> I explicitly stated that I'm not voicing an opinion either way. And I
> don't want to.
You don't seem to want anyone to, which is unfair and counterproductive.
>> And I believe that your "critique" (if it can be called that) is
>> baseless and completely unjustified.
>>
>
> Look, I believe that Mozilla shouldn't voice an opinion either, lest set
> any requirements in this respect about this subject. Remember that
If Mozilla avoided doing or saying anything that could theoretically be
used in future litigation, it would be frozen into inaction. Instead,
it tries to make the best decisions possible on behalf of its users,
without introducing undue liability to itself.
> Just consider Mozilla would head the battle cry of years from Ian and
> adopt such a stupid requirement, and the next day a court throws it out
> of the window at the first opportunity and press for charges and
> compensation... Guess who the affected party would sue next.
It's not nice to call others' ideas stupid.
Requiring an explicit standardized disclaimer of liability doesn't
remove any other liability-minimizing steps that CAs can take, thus it's
hard to imagine how this increases their exposure or, by extension,
Mozilla's.
The only thing that separately might be prohibited is RPAs, which aren't
doing CAs any good anyway, and are a separate question in any case.
> Seriously, if you think Mozilla should mess with it, let their lawyers
> make a recommendation if, how, when it should do that. Just my advise,
> do what you want.
I am quite sure that their lawyers monitor any changes to the policy,
and if they aren't already then they should be for a variety of reasons.
> (I'm not against anybody voicing an opinion, but I'm against making
> statements that appear to look as if they are the golden truth by
> repeating them over and over again.)
In that case, provide some meat to your theorizing instead of simply
repeating that the others are wrong.
When you get around to doing that, I'll respond. Until then, I'm done.
Ian G
> On 7/13/11 5:02 PM, Jeremy Rowley wrote:
>
> Netscape. However, there haven't been any that challenged the central
> finding that I cited.
>
> Just for fun I took a minute to look through all Westlaw negative
> treatment of Specht. There are 10 cases, and none of them challenge this
> premise.
>
> Of course, there may be some obscure case that you have in your back
> pocket. I and the rest of the cyberlaw scholarly community would love to
> see it.
Steve,
So, it may be that a future law case will follow that path and find no
privity. The problem with this future is that it will still take some
time. I'd expect that sort of case to take a decade, as we want some
appeals in there, and it's hardly going to get expedited.
In the meantime, what have we got? If the RPA is upheld, the user gets
nothing. If the RPA is not upheld, what is the user's cause of action?
Do you agree that even if the RPA is not upheld, the user has
practically no cause of action against the CA? Or an unreliable path in
any cause of action?
iang
Stephen Schultze
> browsers fail to display or relay this link to the end-user (both of which
> are true), then your main issue with enforceability is with the browser, not
> the CA.
You would need to establish that the browser has some duty to convey
this information to the end user, which that have agreed to do with the
CAs. If instead the CAs proceed with their business with the knowledge
that the RPAs won't be valid, but represent somehow that they are, they
have a problem. Perhaps they can get rid of this problem by requiring
indemnification from all Subscribers (the most likely parties to be
sued), which is what they do.
In any case, the point remains... as of today's implementation, RPAs
have no effect.
Jeremy Rowley
assumption that "there is simply no reasonable interpretation of current
certificate usage that wouldn't fall prey to the same problem of Specht,
namely "a reasonably prudent Internet user in circumstances such as these
not adequately supported.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Stephen Schultze
Sent: Wednesday, July 13, 2011 3:32 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 7/13/11 5:02 PM, Jeremy Rowley wrote:
> I remember Specht v. Netscape. There have been cases since then.
That is true. There have even been many cases that cited Specht v.
Netscape. However, there haven't been any that challenged the central
finding that I cited.
Just for fun I took a minute to look through all Westlaw negative
treatment of Specht. There are 10 cases, and none of them challenge
this premise.
Of course, there may be some obscure case that you have in your back
pocket. I and the rest of the cyberlaw scholarly community would love
to see it.
Stephen Schultze
> My point was that not all browser agreements have been held invalid. You're
> assumption that "there is simply no reasonable interpretation of current
> certificate usage that wouldn't fall prey to the same problem of Specht,
> namely "a reasonably prudent Internet user in circumstances such as these
> would not have known or learned of the existence of the license terms" is
> not adequately supported.
Of course not all browser agreements have been held invalid. There are
many many examples. That alone doesn't tell us anything.
The only way my assertion could be more supported is a very specific
lawsuit with this exact fact-pattern. If you think "a reasonably
prudent Internet user in circumstances such as these would not have
known or learned of the existence of the license terms" you have to
explain how on earth that would happen.
Jeremy Rowley
who are made aware that the RPA exists.
Why should CAs require indemnification from all subscribers? As I pointed
out before, If you don't believe a contact claims exists, then there isn't a
cause of action.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Stephen Schultze
Sent: Wednesday, July 13, 2011 3:43 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 7/13/11 4:32 PM, Jeremy Rowley wrote:
> Plus, if each certificate includes a link to the relevant RPA and the
> browsers fail to display or relay this link to the end-user (both of which
> are true), then your main issue with enforceability is with the browser,
not
> the CA.
You would need to establish that the browser has some duty to convey
this information to the end user, which that have agreed to do with the
CAs. If instead the CAs proceed with their business with the knowledge
that the RPAs won't be valid, but represent somehow that they are, they
have a problem. Perhaps they can get rid of this problem by requiring
indemnification from all Subscribers (the most likely parties to be
sued), which is what they do.
In any case, the point remains... as of today's implementation, RPAs
have no effect.
Stephen Schultze
> Do you agree that even if the RPA is not upheld, the user has
> practically no cause of action against the CA? Or an unreliable path in
> any cause of action?
That would be the logical conclusion, although that hasn't been tested
in court (ie: we don't know whether one could somehow imply a direct
cause of action of a RP against a CA).
The Subscriber has the most exposure, and the exposure of the CA comes
down to the strength of it's indemnifications that were required from
the Subscriber.
RPAs are pointless and only serve to confuse.
Stephen Schultze
> They do have an effect, especially for users who know about certificates or
> who are made aware that the RPA exists.
Who are these mythical users? Certainly not the vast majority of
Mozilla users.
> Why should CAs require indemnification from all subscribers? As I pointed
> out before, If you don't believe a contact claims exists, then there isn't a
> cause of action.
I don't believe a contract claim exists between the CA and the RP, but
in very many cases one exists between the RP and the Subscriber. Don't you?
Jeremy Rowley
validity of the RPA would depend on the fact pattern.
Here's an obvious example: Mr. Schultze wants to use a certificate to
complete an online transaction. Mr. Schultze is aware of the certificate
and the RPA attached to the use of the certificate and has read the RPA
before agreeing to the purchase. In fact, Mr. Schultze contacted the CA and
even asked additional questions about the RPA before making the purchase.
You claimed that Eddy "will discover that all other reasonable legal
professionals will come to a similar conclusion". I disagree.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Stephen Schultze
Sent: Wednesday, July 13, 2011 3:49 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 7/13/11 5:45 PM, Jeremy Rowley wrote:
> My point was that not all browser agreements have been held invalid.
You're
> assumption that "there is simply no reasonable interpretation of current
> certificate usage that wouldn't fall prey to the same problem of Specht,
> namely "a reasonably prudent Internet user in circumstances such as these
> would not have known or learned of the existence of the license terms" is
> not adequately supported.
Of course not all browser agreements have been held invalid. There are
many many examples. That alone doesn't tell us anything.
The only way my assertion could be more supported is a very specific
lawsuit with this exact fact-pattern. If you think "a reasonably
prudent Internet user in circumstances such as these would not have
known or learned of the existence of the license terms" you have to
explain how on earth that would happen.
Jeremy Rowley
And no - I believe users are more aware of RPAs than you give them credit.
CAs provide site seals with links to these RPAs all the time.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Stephen Schultze
Sent: Wednesday, July 13, 2011 3:57 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 7/13/11 5:49 PM, Jeremy Rowley wrote:
> They do have an effect, especially for users who know about certificates
or
> who are made aware that the RPA exists.
Who are these mythical users? Certainly not the vast majority of
Mozilla users.
> Why should CAs require indemnification from all subscribers? As I pointed
> out before, If you don't believe a contact claims exists, then there isn't
a
> cause of action.
I don't believe a contract claim exists between the CA and the RP, but
in very many cases one exists between the RP and the Subscriber. Don't you?
Eddy Nigg
>
> In that case, provide some meat to your theorizing instead of simply
> repeating that the others are wrong.
I'd be stupid to say that and I haven't said that. But I don't say that
it's correct either, I'm saying that you aren't qualified and not party
to make either claim.
Stephen Schultze
> You are one of these mythical users.
>
> And no - I believe users are more aware of RPAs than you give them credit.
> CAs provide site seals with links to these RPAs all the time.
You're right. Because I have knowledge of the RPA, I personally have a
tough time making this claim against a CA.
Almost anybody else in the world wouldn't. This is what Specht and
subsequent caselaw tells us.
Your analysis has essentially led to agreement with me, because you
can't give anything but an extremely unlikely fact pattern (one in a
million? even less likely?), in which an RPA is arguably enforceable.
Site seals do not solve this problem. First of all, do you want to
hinge your legal strategy on voluntary participation of your
Subscribers? Second, consistent with the fact pattern in Specht, site
seals are typically at the bottom of pages and unlikely to be clicked
on. Third, even the DigiCert seal doesn't indicate that a user is
assenting to terms of service, so if it is seen it doesn't affect their
awareness of the RPA:
http://www.digicert.com/authentication-encryption.htm
Studies of user perception of HTTPS will disabuse anybody of the notion
that users have any idea what is going on behind the scenes, let alone
the legal architecture of those machinations.
I understand why you want RPAs to work, but they don't.
Jeremy Rowley
meat". To date, no lawsuit has tested the enforceability of RPAs. Any
discussion on the issue can ONLY be theory.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Eddy Nigg
Sent: Wednesday, July 13, 2011 4:03 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 07/14/2011 12:36 AM, From Stephen Schultze:
>
> In that case, provide some meat to your theorizing instead of simply
> repeating that the others are wrong.
I'd be stupid to say that and I haven't said that. But I don't say that
it's correct either, I'm saying that you aren't qualified and not party
to make either claim.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
_______________________________________________
Eddy Nigg
>
> In any case, the point remains... as of today's implementation, RPAs
> have no effect.
Mmmhh, isn't this an opinion contradicting what Ian is claiming? Or even
your own claims (not sure)?
Stephen Schultze
> Hold the phone. Your whole argument against RPAs is a theory without "some
> meat". To date, no lawsuit has tested the enforceability of RPAs. Any
> discussion on the issue can ONLY be theory.
Theory can have meat.
Theory can also be more or less plausible.
No assertion about the state of the law is entirely non-theoretical
until you have a case with the exact fact-pattern (meaning exact
plaintiffs), in the exact jurisdiction, upheld by the highest court in
that jurisdiction, under a legal regime that is unchanged from the
status quo.
So if you're saying I don't have an example of a Supreme Court case on
RPAs relating to a specific plaintiff with a specific claim against a CA
under today's law, and that I don't have a guarantee that Congress will
not retroactively change the law as it applies today, I concede.
But the undeniable force of caselaw is still against you.
I really feel that this discussion is reaching DDOS levels for this
list, so I'm going to take a break for 24 hours.
Stephen Schultze
> On 07/14/2011 12:42 AM, From Stephen Schultze:
>>
>> In any case, the point remains... as of today's implementation, RPAs
>> have no effect.
>
> Mmmhh, isn't this an opinion contradicting what Ian is claiming? Or even
> your own claims (not sure)?
No legal effect. They sure as hell are confusing for a lot of people
though.
Ian G
> On 07/14/2011 12:42 AM, From Stephen Schultze:
>>
>> have no effect.
>
> your own claims (not sure)?
I guess I can repeat my opinion again, at Eddy's request :D
My claim is that the legal architecture sets liability to zero between
the CA and the user [0].
Steve's claim is that the RPA has no effect. I partially concede that
point and partially don't, for all the reasons bouncing back and forth
between Jeremy and Steve. It's untested, and very expensive to find out.
But, the reason I don't care so much is because IMHO it doesn't matter.
The RPA was never meant to be ironclad and upheld. It was simply
meant to fill the spot of the contract that set the liability to zero.
Which it does [1]. Admirably.
If it doesn't get upheld, then the user has to establish another cause
of action. We're mostly agreed that this is so tough as to be unlikely.
So the liability again results in zero.
This is why it is a legal architecture, not just an RPA or CPS. It's a
carefully orchestrated plan to make sure that the CA can survive as a
business. I say more about why that is essential in that "An Open
Audit" paper.
Once we're all agreed on that ... the question is, what do we do about it?
iang
[0] I'm avoiding the discussion of RP versus user, because again, it
doesn't matter which way you travel.
[1] Yes, it gets convoluted.... PKI architects prefer Russian Dolls
for soulmates. In classical PKI thinking, the CPS must state who the RP
is and must state the conditions under which an RP may participate. The
Relying Party Agreement provides that in a contract form, and forms a
bridge from Internet PKI to classical PKI, for whosoever wishes to walk
that path. Which is to say, if you subscribe to classical PKI thinking,
then the RPA or equivalent is an essential component.
Jeremy Rowley
RPA. You affirmed that it would.
The problem with your stance on RPAs is that it is grounded in absolutes
that don't exist. Lawsuits, especially in this area, are too fact specific
to apply broad-brushed claims such as "no reasonable attorney" and RPAs have
"no legal effect". You're wrong on this, and caselaw supports my position.
I don't disagree with you that theories can have meat. However, I do
disagree with your presumption that Eddy's theories have less meat than
yours. You can't decide pork isn't a meat simply because you wanted to only
have beef.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Stephen Schultze
Sent: Wednesday, July 13, 2011 4:20 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 7/13/11 6:13 PM, Jeremy Rowley wrote:
> Hold the phone. Your whole argument against RPAs is a theory without
"some
> meat". To date, no lawsuit has tested the enforceability of RPAs. Any
> discussion on the issue can ONLY be theory.
Theory can have meat.
Theory can also be more or less plausible.
No assertion about the state of the law is entirely non-theoretical
until you have a case with the exact fact-pattern (meaning exact
plaintiffs), in the exact jurisdiction, upheld by the highest court in
that jurisdiction, under a legal regime that is unchanged from the
status quo.
So if you're saying I don't have an example of a Supreme Court case on
RPAs relating to a specific plaintiff with a specific claim against a CA
under today's law, and that I don't have a guarantee that Congress will
not retroactively change the law as it applies today, I concede.
But the undeniable force of caselaw is still against you.
I really feel that this discussion is reaching DDOS levels for this
list, so I'm going to take a break for 24 hours.
Gervase Markham
> Therefore I believe the discussion is treading water and I'm biting my
> tongue in order not to offend anybody here.
Bite harder.
(Both of you.)
Gerv
Eddy Nigg
> On 13/07/11 19:04, Eddy Nigg wrote:
>> Therefore I believe the discussion is treading water and I'm biting my
>> tongue in order not to offend anybody here.
> Bite harder.
Since one of my tasks might be to defend a CA it's extremely difficult
to comment publicly on this subject in a way that it couldn't be used
against me in the future.
However - and I hope this is still something I'm allowed to say - as a
starter, there are laws and regulations that a apply to *any*
organization and executive without relation of being a CA. Certain
liabilities can never be disclaimed, neither can gross negligence, even
if an organization disclaims it in a written agreement, statement or
otherwise.
Basically not everything that has been stated by various CAs would stand
the test in court. There is no such thing as zero liability - depending
on jurisdiction and local law it's most of the time impossible (this
applies probably to most, if not all countries in the western hemisphere
I know of). It's not possible to disclaim liability where the law says
otherwise.
It's obviously an extremely difficult topic in any case and I believe
it's not something we should deal with it here. It's also not something
that can be discussed in a free manner without some possible
implications on what the parties say.
Ian G
> On 07/16/2011 01:04 PM, From Gervase Markham:
>>> Therefore I believe the discussion is treading water and I'm biting my
>>> tongue in order not to offend anybody here.
>> Bite harder.
>
> to comment publicly on this subject in a way that it couldn't be used
> against me in the future.
Thanks, it's helpful to all here to have that point made, and loudly.
> However - and I hope this is still something I'm allowed to say - as a
> starter, there are laws and regulations that a apply to *any*
> organization and executive without relation of being a CA. Certain
> liabilities can never be disclaimed, neither can gross negligence, even
> if an organization disclaims it in a written agreement, statement or
> otherwise.
>
> Basically not everything that has been stated by various CAs would stand
> the test in court. There is no such thing as zero liability - depending
> on jurisdiction and local law it's most of the time impossible (this
> applies probably to most, if not all countries in the western hemisphere
> I know of). It's not possible to disclaim liability where the law says
> otherwise.
Sorry, this is an error of expansion of the particular to the general.
Yes, it is legally impossible to reduce liability to zero. This is
because the courts and the law defines what we are liable for, in court,
not us.
However, a person can reduce their liability to effectively zero by
several diverse means. One of those means is a disclaimer in a
contract, which typically says "disclaim liability to the extent
permitted under law" which absorbs and deals with your particular point.
Other strategies exist as well, but it is beyond scope to list them
out in this forum (some would say, ask your lawyer for legal advice...).
It is the *effective liability of zero* we are talking about. The
business level, not the nominal or legal position.
> It's obviously an extremely difficult topic in any case and I believe
> it's not something we should deal with it here.
Where then?
> It's also not something
> that can be discussed in a free manner without some possible
> implications on what the parties say.
Thanks, again, for making the point!
You would then agree that anything done to reduce those implications
would have to be a good thing for all parties?
iang
Eddy Nigg
>
> Thanks, it's helpful to all here to have that point made, and loudly.
It's of course a two sided sword ;-)
But it's not surprising, isn't it? It's obvious and logical.
>
> It is the *effective liability of zero* we are talking about. The
> business level, not the nominal or legal position.
Your interpretations and assumptions might be wrong. And yes, ask your
lawyer who's answers might be every time different depending on which
side he has to represent.
>
>> It's obviously an extremely difficult topic in any case and I believe
>> it's not something we should deal with it here.
>
> Where then?
Nowhere probably. Maybe in a closed forum with relevant legal
professionals involved - if at all. As far as I know, no such need has
arisen so far.
>
> You would then agree that anything done to reduce those implications
> would have to be a good thing for all parties?
No, it's wrong and I don't share your point of view. It's not good for
any party involved and it's also incorrect in my opinion. It's not
something we can decide even if we would, it might not stand up in a
court (which again probably depends on the jurisdiction).
Stephen Schultze
> I just gave you an example where current case law would support upholding an
> RPA. You affirmed that it would.
I will grant you that in the highly improbable scenario that you
constructed, current case law might uphold the RPA.
> The problem with your stance on RPAs is that it is grounded in absolutes
> that don't exist. Lawsuits, especially in this area, are too fact specific
> to apply broad-brushed claims such as "no reasonable attorney" and RPAs have
> "no legal effect". You're wrong on this, and caselaw supports my position.
No, they are not too fact specific to come to broad conclusions. In any
but the most highly unlikely scenario, any reasonable attorney would
conclude that RPAs have no legal effect. Anybody can invent a fact
pattern that gets around a particular precedent. In this case, that
fact pattern is all but irrelevant. Mozilla's cert policy is focused on
"typical users of our software products." Specht involved "a reasonably
prudent Internet user." By either standard, such users would not
reasonably have any idea that RPAs exist, or what they say.
I am right on this, and caselaw supports my position.
> I don't disagree with you that theories can have meat. However, I do
> disagree with your presumption that Eddy's theories have less meat than
> yours. You can't decide pork isn't a meat simply because you wanted to only
> have beef.
I have provided both ample reasoning and clear precedent. I'd say
that's enough to conclude that an alternative that consists of no
reasoning and no legal citation is inferior.
But really, I don't care enough about this issue to continue spamming
the list. RPAs annoy me and probably do some damage given the confusion
they cause, but we have bigger fish to fry.
Jeremy Rowley
someone actually challenges its validity, No one involved in a lawsuit will
want to challenge the validity of the RPA. The RP won't as that would
destroy the basis of their contract claim against the CA. The CA won't as
they drafted the document and have a real interest in seeing the RPA upheld
(plus, as the agreement's drafter, the CA would likely be estopped from
asserting this defense). What this means is that the RPA will remain valid,
regardless of the RP's sophistication, simply because none of the parties
are willing to dispute the issue.
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Stephen Schultze
Sent: Monday, July 18, 2011 8:53 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: BR17.1 - Liability MUST be fully disclaimed.
On 7/13/11 7:19 PM, Jeremy Rowley wrote:
> I just gave you an example where current case law would support upholding
an
> RPA. You affirmed that it would.
I will grant you that in the highly improbable scenario that you
constructed, current case law might uphold the RPA.
> The problem with your stance on RPAs is that it is grounded in absolutes
> that don't exist. Lawsuits, especially in this area, are too fact
specific
> to apply broad-brushed claims such as "no reasonable attorney" and RPAs
have
> "no legal effect". You're wrong on this, and caselaw supports my
position.
No, they are not too fact specific to come to broad conclusions. In any
but the most highly unlikely scenario, any reasonable attorney would
conclude that RPAs have no legal effect. Anybody can invent a fact
pattern that gets around a particular precedent. In this case, that
fact pattern is all but irrelevant. Mozilla's cert policy is focused on
"typical users of our software products." Specht involved "a reasonably
prudent Internet user." By either standard, such users would not
reasonably have any idea that RPAs exist, or what they say.
I am right on this, and caselaw supports my position.
> I don't disagree with you that theories can have meat. However, I do
> disagree with your presumption that Eddy's theories have less meat than
> yours. You can't decide pork isn't a meat simply because you wanted to
only
> have beef.
I have provided both ample reasoning and clear precedent. I'd say
that's enough to conclude that an alternative that consists of no
reasoning and no legal citation is inferior.
But really, I don't care enough about this issue to continue spamming
the list. RPAs annoy me and probably do some damage given the confusion
they cause, but we have bigger fish to fry.
Stephen Schultze
> Look at it from another way. The only way an RPA will be held invalid is if
> someone actually challenges its validity, No one involved in a lawsuit will
> want to challenge the validity of the RPA. The RP won't as that would
> destroy the basis of their contract claim against the CA.
This line of argument also does not work.
The RP's claim is not likely to be based on explicit terms in the RPA
contract. As I have already explained, the liability is likely to flow
through a suit against the Subscriber. It could also be a direct claim
based on some implied duty, foreseeable harm tort, and/or non-waivable
liability.
It simply doesn't make sense to imply that the RP would want to rely on
explicit terms in the RPA for claiming liability when the majority of
RPAs disclaim all liability.
Ironically, the most likely effect of the RPA in a direct suit by an RP
could be to bolster something like a tort claim based on forseeable harm
(there is no contract in place, but via the RPA the CA itself has
explicitly identified the end-user as at risk). Thus, the RPA works, if
anything, against the primary purpose that it serves for most CAs
(disclaiming liability).
For more details on this analysis, see the presentation by my co-author
here:
http://citp.princeton.edu/events/lunch/steven-roosa/
Ian G
> Look at it from another way. The only way an RPA will be held invalid is if
> someone actually challenges its validity, No one involved in a lawsuit will
> want to challenge the validity of the RPA. The RP won't as that would
> destroy the basis of their contract claim against the CA.
Right, or they need to find another basis to get standing in court.
That's the tricky part.
However:
> But really, I don't care enough about this issue to continue spamming
> the list. RPAs annoy me and probably do some damage given the confusion
> they cause, but we have bigger fish to fry.
Right, I join in that.
To be specific, although I also have railed at times against the RPA and
the relying party v. end-user chicanery, I've come to realise that there
is a solution to the gordian knot: the liability.
If we establish the liability as zero across the board, then the
demarcation between RP's rights under RPA and user's rights outside RPA
no longer matters as much.
Liability at zero is a great homogonisation agent :)
iang
Ian G
> On 7/18/11 11:17 AM, Jeremy Rowley wrote (classical RPA stratey):
>> Look at it from another way. The only way an RPA will be held invalid
>> is if
>> someone actually challenges its validity, No one involved in a lawsuit
>> will
>> want to challenge the validity of the RPA. The RP won't as that would
>> destroy the basis of their contract claim against the CA.
>
>
> The RP's claim is not likely to be based on explicit terms in the RPA
> contract. As I have already explained, the liability is likely to flow
> through a suit against the Subscriber. It could also be a direct claim
> based on some implied duty, foreseeable harm tort, and/or non-waivable
> liability.
What would you propose about the recent claim that carding sites are
being issued certificates?
Peter Gutmann reported this site:
> In the meantime I guess we can keep
> trusting [CAs] to issue certs to people
> like https://secondzion1.com/. I believe
> no further action or information is
> necessary. We get the picture.
Does it make any difference if the contracted parties -- CAs and Vendors
alike -- acknowledge this practice as expected and within the model?
> It simply doesn't make sense to imply that the RP would want to rely on
> explicit terms in the RPA for claiming liability when the majority of
> RPAs disclaim all liability.
Right, the RPA (and CPSs) amount to a hill o' beans for the RP.
> Ironically, the most likely effect of the RPA in a direct suit by an RP
> could be to bolster something like a tort claim based on forseeable harm
> (there is no contract in place, but via the RPA the CA itself has
> explicitly identified the end-user as at risk). Thus, the RPA works, if
> anything, against the primary purpose that it serves for most CAs
> (disclaiming liability).
This attack indeed was hypothesised against CAcert's original RPA-copy.
After much consideration, we decided to withdraw it because of the
"cherry-picking" flaw, and replace it with an Internet-style open
licence. But the problem remains (and has always been) that the old PKI
design of direct relationship from CA to user was interdicted by the
vendor, and thus gives rise to complicated legal process.
> For more details on this analysis, see the presentation by my co-author
> here:
> http://citp.princeton.edu/events/lunch/steven-roosa/
Saw that. If there is written text explaining the last few slides, that
would be helpful.
iang
Stephen Schultze
> On 19/07/11 2:26 AM, Stephen Schultze wrote (indirect suit strategy):
>> On 7/18/11 11:17 AM, Jeremy Rowley wrote (classical RPA stratey):
>>> Look at it from another way. The only way an RPA will be held invalid
>>> is if
>>> someone actually challenges its validity, No one involved in a lawsuit
>>> will
>>> want to challenge the validity of the RPA. The RP won't as that would
>>> destroy the basis of their contract claim against the CA.
>>
>> This line of argument also does not work.
>>
>> The RP's claim is not likely to be based on explicit terms in the RPA
>> contract. As I have already explained, the liability is likely to flow
>> through a suit against the Subscriber. It could also be a direct claim
>> based on some implied duty, foreseeable harm tort, and/or non-waivable
>> liability.
>
> What would you propose about the recent claim that carding sites are
> being issued certificates?
To the extent that all the CA is doing is validating domain control, and
to the extent that this is the reasonable interpretation of the RPs, I
don't see how it relates.
>> Ironically, the most likely effect of the RPA in a direct suit by an RP
>> could be to bolster something like a tort claim based on forseeable harm
>> (there is no contract in place, but via the RPA the CA itself has
>> explicitly identified the end-user as at risk). Thus, the RPA works, if
>> anything, against the primary purpose that it serves for most CAs
>> (disclaiming liability).
>
> This attack indeed was hypothesised against CAcert's original RPA-copy.
> After much consideration, we decided to withdraw it because of the
> "cherry-picking" flaw, and replace it with an Internet-style open
> licence. But the problem remains (and has always been) that the old PKI
> design of direct relationship from CA to user was interdicted by the
> vendor, and thus gives rise to complicated legal process.
I don't know what you mean by "withdraw it," the "cherry-picking flaw,"
or "and internet-style open licence." In any case, I agree that it
gives rise to a complicated legal process.
>> For more details on this analysis, see the presentation by my co-author
>> here:
>> http://citp.princeton.edu/events/lunch/steven-roosa/
>
> Saw that. If there is written text explaining the last few slides, that
> would be helpful.
No, but there is an audio recording of the presentation on that same
page, which goes into more detail.
The analysis itself is fairly straightforward application of torts.
Ian G
> On 7/21/11 1:11 PM, Ian G wrote:
>> What would you propose about the recent claim that carding sites are
>> being issued certificates?
>
> To the extent that all the CA is doing is validating domain control, and
> to the extent that this is the reasonable interpretation of the RPs, I
> don't see how it relates.
That's more or less what (someone at) Mozilla said when I asked :)
If that were consensus of this group, perhaps we need to rewrite BR
document. Starting from the title:
Baseline Requirements for the Issuance and Management
of *Publicly Trusted Certificates*
If we were to place BR in front of our reasonable man, would he conclude
one of:
(a) oh, they are conducting domain validation?
(b) these certificates are Trusted for use by the Public?
(c) the businesses I am dealing with is Trusted!
(d) everything is Trusted, therefore I am Safe?
I think I recall in lots of other places (Firefox?) there are messages
to effect: "You trust this website!" Or you don't, as the case may be.
Is there a discord between the word TRUST and the term DOMAIN VALIDATION?
Enough to give rise to a cause of action?
iang
PS: an alternate logic: