On 13/12/08 18:25, Frank Hecker wrote:
Ian G wrote:
A possible solution is an open end-user offer. I have before mentioned
that each CA should have a relying party agreement or similar;
something on offer to the mozo end-user. It should be the minimum, or
default, or entry-level document for the end-user. It should apply
even if the user never saw it, like an open source licence. It should
set liabilities between CA and end-user.
It sounds like you're referring to something like a PKI Disclosure
Statement idea that's been discussed in the past:
http://www.verisign.com/repository/pds.txt
Heading in the right direction, because that is a simple and readable
document.
But the emphasis is different. That document asks for a mini-CPS.
What I am thinking is more like the RPA ("relying party agreements"),
already found on most CAs sites. This is not a PKI document but a legal
document, and a business document. This is what the lawyer wants to
see. The lawyers forced it on the CAs, not the PKI people.
Some CAs do indeed have these, but not all.
There are three reasons I would not propose it.
1. it seems to have a bug: everything is a SHALL which means if you
don't like one section, you don't do the document, at all. This was
probably unintended.)
2. it includes things that should not be there, as below.
3. it is emphasising PKI not legal relationships.
(actually they are all related, maybe the same bug.)
The reason for doing an RPA is that it draws a straight line from the
end-user to the CA, for all the parties and stakeholders, and especially
the lawyers. Right now, there is a connection, but no reliable map, and
anyone can walk the path, but in many different ways. What we need is a
route map. The RPA is that; an RPA lists the primary route.
Which explicitly removes the vendor from the primary route. Which
addresses the issue of due diligence with unreadable CPSs.
iang
PS: more explanatory notes:
The offer I have in my mind includes (roughly compared to that RFC's
fields):
Name, URL of the CA, whatever for a legal offer.
The disclaimer on liabilities, warranties, indemnities, etc.
Applicable law + forum of dispute resolution
Maybe no more than that? Again from the RFC, it would be optional to
include:
Certificate type: likely all are covered
Statement on Reliance, if so, how, etc.
Information & status checking obligations
Including these things would depend heavily on ones views on PKI. And
these things would be definately wrong:
subscribers: they have another agreement.
Applicable agreements: irrelevant, there is only this one.
privacy policy: the end-user's privacy is not at issue
Refund policy: the end-user didn't pay a buck.
Especially, this last one:
CA and repository licenses, trust marks, and audit
is exactly the thing that is not wanted in an RPA or end user offer.
That's guaranteed to sent your legal cousel into paroxyms...
All the existing RPAs I have skimmed match this view. There is nothing
novel about this; we just need to appreciate it and make it clear that
this is the standard approach in the legal perspective of CAs.
https://www.verisign.com/repository/rpa.html
(I hate to pick on Verisign, but their RPA is the best one for
explanatory purposes. It's clear, short, easy to read, and there are
reasons to believe it is the state of the art in legal perspectives.)
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
