Subject: RE: Request for IESG consideration: CP/CPS Framework

From: "Adrian McCullagh" <[email-masked]>
Date: Fri, 22 Nov 2002 15:57:44 +1000

Dear David,

If one looks at the raison d'etre for a CPS it is very different to that of
the CP.

It is my understanding, and I am open to any correction, that a CPS is a
document that details the practices and procedures established by a CA that
will cover the life-cycle of certificates issued by the CA.  That is it
covers how the certificate will be generated, suspended and revoked.  An
internally focused document covering the internal environment of the CA.
Much like an operations manual for a CA business as they relate to
certificates.

The CP is a very different document which will usually be relied upon by
the relying party and to a certain extent the subscriber.  RFC 2527 states
:

'According to X.509, a certificate policy (CP) is "a named
set of rules that indicates the applicability of a certificate to a
particular community and/or class of applications with common
security requirements."
A CP may be used by a relying party to help
in deciding whether a certificate, and the binding therein, are
sufficiently trustworthy and otherwise appropriate for a particular
application.'

Hence my query as to the applicability of RFC 2527 to the CP.  RFC 2527
concentrates of the internal practices of the CA, which is really the
function of a CPS.  I believe that a separate RFC should be established
that specifically covers the rules that govern the use of a certificate by
a relying party.  This RFC should be much more concise than RFC 2527.
Hence my comment that I believe RFC 2527 to be inappropriate for a CP and
thus overly complex.

It is interesting that the Banking sector has taken the view that a CPS is
an internal document, which I have no problem with, and therefore will not
be published.  A CP on the other hand does need to be published otherwise
the relying party will not be in a position to ascertain/determine any
trust value for the transaction as it relates to the digital signature for
verification.

Dr. Adrian McCullagh Ph. D.
Solicitor/lawyer
Freehills, Australia

Direct 61 7 3258 6603
Telephone 61 7 3258 6666
Facsimile 61 7 3258 6444
http://www.freehills.com

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------

---

From: "Marc Poulaud" <[email-masked]>
Date: Fri, 22 Nov 2002 09:19:12 -0000

David,

I agree with most of your points here. There has been much confusion over
the purpose and applicability of a CP and CPS. Even in my experience of
the banking sector/scheme space. One additional way of looking at the
difference is the CP specifies the 'what' and the CPS specifies the 'how',
and as such I think having the 2527 framework makes sense from this
perspective (although having had to write these pairs, it's not as easy as
it sounds) and I'm not convinced of the value.

Also, from my banking scheme experience, the CPS is confidential but
includes the subscribing customer, but not the relying customer. A fairly
light and common CP across both parties essentially points to a Customer
Agreement that takes into account a common set of contractual agreement
clauses. This is what binds the parties together from a legal perspective
and hence the level of trust.

In the real world, does anybody really check or care what is in a CP or
the CPS? I think it depends on the circumstances and the scheme around
this.

From my point of view, a CPS is generally a good-practice as it focuses
the CA provider and auditors minds. A CP is good because it can point to a
legal/contractual framework.

Also to consider are signature policies - shirely any framework/changes
should take into account of these too.

Marc.
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Adrian McCullagh
Sent: 22 November 2002 05:58
To: Fillingham, David W.
Cc: 'Adrian McCullagh'; [email-masked]; [email-masked]; Jeffrey
I. Schiller; [email-masked]; 'Paul Hoffman / IMC';
[email-masked]
Subject: RE: Request for IESG consideration: CP/CPS Framework

Dear David,

If one looks at the raison d'etre for a CPS it is very different to that
of
the CP.

document that details the practices and procedures established by a CA
that

Direct 61 7 3258 6603
Telephone 61 7 3258 6666
Facsimile 61 7 3258 6444
http://www.freehills.com

---

From: "Alice Sturgeon" <[email-masked]>
Date: Fri, 22 Nov 2002 15:41:39 -0500

And another country ...
I completely agree with Adrian on the differences between CP and CPS, but
not that this dictates separation of the two.  Several of us in this field
have argued for years that a CPS should not be published, because doing so
would introduce vulnerabilities, given that a CPS should contain details of
system security mechanisms in place.  And that's why I for one was happy to
see acceptance of the PKI Disclosure Statement, which gives evidence of the
existence of a CPS, and some of the high-level and most salient points of
it, while obviating the need for publication of the CPS.
2527, and its revision waiting in the wings, is a framework, and a useful
one as Rich points out for external interoperability and internal policy and
procedural development.  I do not see the need for two separate documents
because a drafter should be able to glean the elements pertaining to CP or
CPS from the framework presented.  In other words, 2527 does not give finely
granular (as the techs say) detail to guide drafters of CP/CPS's; it
provides an overview, a framework.  A potential danger with separating
CP/CPS into two standards (or guidance documents) is that they would become
too separate; that only one would be referenced and used, whereas their
relationship is inherent and inextricable.
I agree with others who have posted concerning whether 2527 should be
informational or a proposed standard within IETF, that machine processing
may not be the ultimate goal, and therefore rigid adherence to ASN.1 specs,
as Santosh notes, is not provided, and was not intended to be provided.  At
this point, it probably does not matter much whether 2527 (and its
understudy in the wings) is informational or a proposed standard, because it
has been accepted globally as the standard.  Ann noted some instances.  It
has been replicated, as well, within other standardization bodies - note,
for example, ISO TC 215's TS 17090 (Technical Specification), PKI for
healthcare.  Of interest to note that this TS points to 2527 as a "normative
reference", meaning that those complying with the TS must comply with 2527.
Whether 2527 is itself informational or a standard becomes moot.

Khaja wrote:
2527 does seem to be built on the assumption that the CA, subscribers
and relying parties are distinct legal entities.  This seemed clear to
me although, to the best of my recollection, this is not explicitly
stated anywhere.  (Please let me know if I am incorrect about either of
the two foregoing points.)"
I would argue that 2527 does make this clear - one point is the roles and
responsibilities section - and the revision, I believe, makes it even more
clear.

Finally, I agree with Ann about the PKI audit; the fact is that 2527 is
being used as the audit base, and that therefore it must be up-to-date and
reflect the current state of the world with respect to PKI implementations,
and this is real world - this is being done; 2527 is being used as the audit
base.  Again, whether 2527 (and daughter-of-2527) is informational or a
proposed standard within IETF is academic; communities of interest (e.g.,
healthcare entities in the U.S. moving towards HIPAA compliance) will
determine whether the framework is mandatory for their own COI.  As IETF
members working on this, it is incumbent on us to make it the best possible
framework.

My $.02 - Canadian (i.e., about $.012 U.S.).

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     613-232-2350
Cell:         613-291-0331

-----Original Message-----
From: Adrian McCullagh [mailto:[email-masked]]
Sent: November 22, 2002 12:58 AM
To: Fillingham, David W.
Cc: 'Adrian McCullagh'; [email-masked]; [email-masked]; Jeffrey I.
Schiller; [email-masked]; 'Paul Hoffman / IMC';
[email-masked]
Subject: RE: Request for IESG consideration: CP/CPS Framework

Dear David,

Direct 61 7 3258 6603
Telephone 61 7 3258 6666
Facsimile 61 7 3258 6444
http://www.freehills.com

---

From: Al Arsenault <[email-masked]>
Date: Mon, 25 Nov 2002 09:53:09 -0500

(Trimming the cc: list a little; hopefully, we haven't dropped anybody
significant.)

First, for those not at the SAAG meeting in Atlanta last week, Jeff and
Steve said that they believe this document (2527bis) will eventually be
published; it's mostly a matter of educating IESG members.

Second, a couple of comments.  I guess I'm surprised at the objections to
publishing a CPS.  For a public CA, publication of a CPS is (almost)
mandatory if you want to engender confidence in your would-be customers.
That's why folks as disparate as VeriSign
(http://www.verisign.com/repository/CPS/)  and the Hongkong Post Office
(http://www.hongkongpost.gov.hk/5digital/dc4_fr.html) publish theirs.  I
don't really believe that publication of that document will reveal any
security vulnerabilities that aren't otherwise obvious.  I'd be interested
in knowing what vulnerabilities someone can glean from those.

Of course, if the PKI in question is a "private" one; e.g., for internal
company use, or use only between a company and its approved partners, it's
likely that a CPS is just like other non-public business information, and
not generally disclosed.  But that would relate more to business practices
and competitive advantage than to explicit security vulnerabilities in a
system.

That's my .02 (in any currency you'd care to name; 2 Hong Kong cents might
be its approximate worth. :-)

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

----- Original Message -----
From: "Alice Sturgeon" <[email-masked]>
To: "Adrian McCullagh" <[email-masked]>; "Fillingham, David
W." <[email-masked]>
Cc: <[email-masked]>; "Jeffrey I. Schiller" <[email-masked]>;
<[email-masked]>; "'Paul Hoffman / IMC'" <[email-masked]>;
<[email-masked]>
Sent: Friday, November 22, 2002 3:41 PM
Subject: RE: Request for IESG consideration: CP/CPS Framework

> Cc: 'Adrian McCullagh'; [email-masked]; [email-masked]; Jeffrey
I.
of
that