[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Certificate Policy vs Certification Practice .. where are the boundaries? ... what belongs where?
I agree pretty thoroughly with what Todd says. The PAG (PKI Assessment
Guidelines) of the ABA Info Security Committee is attempting to address both the
CP/CPS distinction, and the need for a consistent PKI technical/legal vocabulary
- including the presentation of different views where there is not yet
consensus.
Chas Merrill, Co-Reporter of the PAG
pkix4@raleigh.ibm.com wrote:
> The following is being forwarded to the pkix4 mailing list.
> Message originally sent by "Winchel 'Todd' Vincent, III" <Winchel@mindspring.com>
> ---------------------------------------------------------------------------
>
> I apologize in advance for the cross posting. I think this post is relevant
> both to the technical and legal community. However, I'm not sure how many
> people are listening on the PKIX Framework list (at IBM,
> pkix4@raleigh.ibm.com) . . . (not the PKIX list, ietf-pkix@imc.org) . . .
> because the IBM list has been dead. I think the proper place for this
> discussion (if any) is on the IBM list.
>
> <Juan Rodriguez-Torrent>
> > During the facts gathering effort the editorial committee received many
> > comments regarding the relationship between Certificate Policy and
> > Certification Practices. All these comments seem to point at the "need to
> > better define the difference between a CP and CPS".But what did strike me
> > the most was the passion that some people showed when this subject
> > surfaced. Several of these "passionate" critics are subscribers in this
> > list but have not mentioned once anything regarding this subject. Do I
> have
> > to believe that this is no longer an issue? or if it is still an issue why
> > not discuss it now?
> </Juan Rodriguez-Torrent>
>
> Juan, you are right. However, I think the editorial committee has an
> obligation to pose questions to the community based on the comments it has
> received to date. We haven't heard anything from the editorial committee
> other than posts to the list about what the new outline will look like.
>
> I wonder if I am one of those people who are considered "passionate" about
> this issue. Although I have opinions about what the difference *should* be,
> I'm not sure that what I believe reflects what industry experts actually
> think it *is*. As an "academic" I can ask a lot of questions, sit around
> and think, and study the documents (which I do), but I believe industry
> experts should weigh in on the issue and give specific examples of actual
> ways in which the documents are *being* used and the problems that arise
> that need to be solved. It would be nice to have a requirements document
> for policy statements -- what is it that we're really trying to accomplish?
> That is the first step in deciding how to accomplish it.
>
> The questions I posed at the PKIX/ABA ISC meeting before RSA 1999
> (abbreviated version posted below) seemed to be well-received, but have not
> been discussed or answered by anyone openly (to my knowledge), including the
> editorial committee. I certainly don't know of anything that has been
> published. Unfortunately, there seems to be a desire to only slightly
> tinker with the Framework. This is a shame. The Framework is a great
> start, but it is only a start. Indeed, lawyers, consultants, business
> people, and users would like to implement and/or benefit from the services
> PKI offers, but the underlying technology and the legal/policy issues
> surrounding PKI are not well-understood. The "non-experts" don't get it and
> the "experts" don't seem to agree when asked about the details. As a
> result, there are many who dislike PKI or are taking a wait-and-see
> approach. This will change, of course. The question is how quickly. At
> RSA 1999, I recall a speaker saying something like, "last year, we said,
> 'this is the year of PKI' . . . maybe it wasn't, but this year is going to
> be . . . " . . . I wonder whether that will be said again at RSA 2000. The
> point is, the sooner we answer some of these questions definitively, the
> closer we'll be to wider and more rational deployment of PKI.
>
> I would very much enjoy knowing the opinions of the editorial committee (and
> others) on the following questions. Perhaps everyone agrees. If so, we can
> write it, publish it, and everyone will be better off. If everyone does not
> agree, then we should identify and resolve the issues.
>
> (Note: As most of you who know me are aware, I am a strong advocate of
> machinable legal and policy statements using XML -- or, at least, whatever
> syntax makes people feel most comfortable. This is a separate issue from
> the issues posed below. However, I do believe that some of the legal/policy
> issues can be solved better using "smart" technology. I am not, however,
> attempting to open this can of worms here . . . but reserve the right to do
> it later :-)
>
> I hypothesize that technologists, lawyers, policy makers and users might
> answer these questions very differently. I might be wrong, I'm not sure.
> That's why I ask.
>
> 1. What is the Relationship of, and Difference between, Certificate Policy
> and Certificate Practice Statement
>
> a. Define the Difference Between Certificate Policy and Certificate
> Practice Statement
>
> b. Define Expected Author of Each Document (legal, accounting/auditor/,
> technical)
>
> c. Define Relationship Between Certificate Policy and Certificate
> Practice Statement (e.g., one-to-one, one-to-many, many-to-many)
>
> d. Define Relationship among Certificate, CP, CPS, and Object
> Identifier
>
> i. Define Ancillary Documents (e.g., Subscriber Agreement, Relying Party
> Agreement, Interoperability Agreement)
>
> e. Define Audience of Each Document (e.g., End Entities, Auditors,
> Governments, Customers)
>
> f. Define Proprietary Nature of Each Document
>
> 2. Define Roles in a Public Key Infrastructure and the Expected Functions of
> Each Role
>
> a. Policy Authority
>
> b. Certification Authority (PKI Service Providers)
> i. Issuer
> ii. Certificate Manufacturer
> iii. Repository
> iv. Registration Authority (Registrar)
>
> c. End Entities
> i. Subscriber
> ii. Relying Party
>
> d. Define Other Roles (If Necessary)
> i. Software Manufacturer
> ii. Key Managers
> iii. Government
>
> 3. Is there a Need for a Common Set of PKI Technical and Legal Definitions?
> Should such a set of definitions be promulgated in the IETF? Should there
> be something like an "ETerms" repository with standardize PKI terminology?
> Should this terminology be linked in a standardized way to PKI workflow . .
> . Ok, forgive me . . . I digressed . . .
>
> Winchel "Todd" Vincent III
> Attorney and Technical Researcher
> Project Director, E-CT-Filing Project
> Georgia State University
> J. Mack Robinson College of Business, eCommerce Institute
> and College of Law
> Phone: (404) 651-4297
> Fax: (404) 651-2092
> Email: winchel@mindspring.com
> Web: http://e-ct-file.gsu.edu/
> Legal XML: http://www.legalxml.org/
begin:vcard
n:Merrill;Charles
tel;fax:973.624.7070
tel;home:973.514.1779 - no voicemail
tel;work:973.622.4444 - has voicemail
x-mozilla-html:TRUE
org:http://www.mccarter.com;http://www.pkilaw.com ===> last update 7/22/99 <=====
version:2.1
email;internet:cmerrill@concentric.net
title:McCarter & English LLP, Newark, N.J.
adr;quoted-printable:;;Four Gateway Center,=0D=0A100 Mulberry St;Newark;NJ;07101-0652;USA
x-mozilla-cpt:;-16976
fn:Charles R. Merrill
end:vcard