RE: Update of RFC 2527 - opposed

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Khaja:

Please see my responses in-line in [].

-----Original Message-----
From: Khaja Ahmed [mailto:khaja.ahmed@xxxxxxxxx] 
Sent: Monday, November 25, 2002 12:35 PM
To: Santosh Chokhani; 'Terwilliger, Ann'; ietf-pkix@xxxxxxx
Subject: RE: Update of RFC 2527 - opposed


Santosh,

I think my point is being colored with points made by others.

I have not said or implied that 2527 is not / has not been useful.  It
has
been quite useful to me.   Clearly it has been useful to many others.
My
point is just that there are some uses / models of PKI which are
substantially different from that discussed in 2527.

[Santosh Says: When we drafted 2527 and its successor, we were
intentionally model and usage neutral.  Based on your comment, I looked
at the document again.  I did not find any constraints on the usage or
model.  VeriSign folks have used this framework for commercial offering
and small and large Enterprises have used the model for their Enterprise
PKI.  If you point out any limitations or constraints that we have
imposed, the authors will be glad to consider removing those, if
appropriate.  Again, any time, specific actionable comments on a
document are helpful.  That becomes even more imperative so late in the
game when the document should have been published a year ago and just
fell through the cracks due to some snafu] 

Ill try to address your question on what changes are needed in the
document to cater to this need.  I don't think this is a matter of any
particular change to any particular section.  It isn't even just that
certificate subscribers are customers or employees.  It is (or so it
seems to me) a fundamentally different way of using PKI and I am trying
to figure out how we can have a document analogous to 2527 to help with
that.

The fact that subscribers are employees or customers is only one part of
the difference.  In the case of employee-subscriber scenario, depending
on the application and role of employee,  the certificate issuer, user
and subscriber may be one legal entity.  However, the particular case I
am thinking of is one in which the CA is the sole relying party.  I have
seen this in at least two reasonable sized applications.

In the canonical version of this model, a business has an application
that is used by it's customers.  The business issues certificates (and
perhaps
SmartCards) to these customers.  These tokens are used to authenticate
the customers when they connect to the service provided by the business.

What would otherwise be a CP simply does not exist in this scenario.
Certainly not in the shape that the 2527 frame work envisions it.  Why
would one be needed?

[Santosh Says: It is up to the business whether they have a CP or not.
If they assert a policy OID in the certificate, they should have a
policy.  The framework makes this clear that if some sections are not
applicable, you can claim no stipulation.  However, I assume that the
business will state how they perform initial registration of the
customers, how they revoke customers, how customers should care for
their token, etc. etc.  All of these should be in a CP.  If the business
decides to run a PKI without any policy and not assert policy OID, I do
not think the framework says you must have one.  But, in this case, I
see a value to addressing some of the issues that the customer and
business will be concerned with and the 2527 framework covers them]

The CPS does exist but in a distributed fashion.  It is scattered
between application standards, operations guide for the application (of
which PKI is simply seen as the auth/security component), the customer
registration process and the customer agreement.  There is no distinct
document called the CPS.  This makes part of the CPS very private
(operations manual) and parts of it very public (customer agreement).

[Santosh Says: I am not sure what to make of your jumping from CP to
CPS.  In either case, be it a CP or CPS, it is always distributed.  I
have applied or advised several Enterprises (private and public) and
commercial service offerers.  Invariably, the components are
distributed, typically: one or more CA (with some trust relationship
among them), RAs, trusted agents, repositories, relying parties,
subscribers and their tokens.  Generally, these components are
physically and logically distributed and are under administrative
control of multiple parties.  I have not seen any problem in applying
the framework to them.  It is upto you whether to have one CP and one
CPS or multiple.  Typically, for compliance audit reasons, we have used
multiple CPS.  But, I know one customer uses one CPS.]

In another application under development, in addition to the CA relying
on subscribers certificates, the subscribers rely on certificates of the
service.  Subscribers do not have to rely on each others certificates.
The CA organization is a sort of a trusted communication hub.  All
customers only trust assertions signed by the hub.  The hub needs to
have subscribers make signed (NR) assertions to it.  To some, these are
critically important applications and uses and need to be put together.

If you feel that the 2527 adequately address this do let me know.  I
realize also that you may feel that this is too specific or non standard
a matter for the document to address.  It is also likely that the list
will feel that this model is not in scope and need not be addressed at
all.  All I would say that that this is very much a needed solution and
each implementation is cutting it's own path now.  Even a BCP would be
helpful at this point.

[Santosh Says: I do not feel these are too specific.  The RFC does not
say that a CA can or can not be a subscriber or replying party.  I think
RFC accommodates these models.]

Khaja

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Santosh Chokhani
Sent: Thursday, November 21, 2002 4:23 AM
To: 'Khaja Ahmed'; 'Terwilliger, Ann'; ietf-pkix@xxxxxxx
Subject: RE: Update of RFC 2527 - opposed



Khaja:

You state:

"It is not very helpful in setting up a CA used internally by an
organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be
a separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with."

Can you elaborate what needs to be changed in the document for dealing
with employees and customers?

I would like to know more of technical and policy aspects as opposed to
legal aspects and how old Section 2 and new Section 9 needs to address
employees and customers since the whole thread began with the claim that
we do not want to make this too much of a legal document.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Khaja Ahmed
Sent: Thursday, November 21, 2002 2:03 AM
To: Terwilliger, Ann; ietf-pkix@xxxxxxx
Subject: RE: Update of RFC 2527 - opposed



Ann,

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.)  As Mack has pointed out, it is increasingly
common to have CA's setup for internal use by an organization or for a
closed community like an organization and it's customers.  For these
situation 2527 can be problematic in the hands of auditors (internal or
external) and even implementers who do not understand this. It is not
always/fully appreciated that this is an informational RFC.

Your point about it being helpful as a checklist is very valid for
public CAs. It is not very helpful in setting up a CA used internally by
an organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be
a separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with.

Khaja

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Terwilliger, Ann
Sent: Wednesday, November 20, 2002 3:50 PM
To: ietf-pkix@xxxxxxx
Subject: RE: Update of RFC 2527 - opposed



Another country is heard from......

Like Mack, I do not believe that automated review of a CP or CPS is
practical (even though it might be desirable).  I also agree that in
many, if not most, instances the CPS will not be made public.  However,
I have to disagree with his conclusion that RFC 2527 is not relevant.

RFC 2527 does provide a checklist for what areas need to be covered in
establishing and operating a CA.  The fact that some of the questions
are not as relevant today as they might have been when it was first
drafted only reinforces the fact that it should be updated to reflect
current conditions. There are other standards that address CA operation
(e.g., X9.79, WebTrust Audit for CA, the ABA document) but virtually all
reference RFC 2527.

I would like to believe that all CA operators are knowledgeable about
PKI and adhere to best practices for operating their CA.  However, that
is a fairy tale--something on a par with the tooth fairy--and there
needs to be some process to ensure that the CA has established good
security practices and follows them.  Hence audits become necessary.

Audits by their very nature are comparing something against a checklist
or standard.  Auditors who are familiar with PKI are capable of adhering
to the spirit of the standard rather than the exact letter if parts of a
standard do not apply.  Unfortunately auditors who are not familiar with
PKI may perform audits more or less by rote.  To me this makes it more
important, not less so, that we continue to update RFC 2527.


-----Original Message-----
From: Hicks, Mack [mailto:Mack.Hicks@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, November 20, 2002 1:10 PM
To: ietf-pkix@xxxxxxx
Subject: Update of RFC 2527 - opposed



I have not posted on this list for some time, lurking has been fun
though. I will say something that some might consider radical.

I thought you might like to know how some of the business world is
looking at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry
and topic of RFC 2527 must be covered by the CA or one gets an "audit
exception" or operations questions. This is done as a rote exercise.
Back when CAs were new, the checklist made sense - now some of the
questions and sections is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application;
the policy is only there to tell any relying party that they should have
a contract with someone before trusting this certificate. The meaning,
impact, legality, effectiveness, application, etc. of a certificate is
addressed in contract (and subject to contract law - as I understand
it). There is no detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA
and related software (OCSP, CRL, LDAP); the CPS is not made public.
Therefore the original goal of automated or assisted examination of a CP
and CPS by a relying party is thwarted. (I supported the automation
goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone
around the neck of CA operators - a barrier to entry into PKI. Therefore
RFC 2527 is purely informational to constructing a CA; I would prefer
that it move toward elimination as standard.



Mack Hicks, SVP
Bank of America  760-318-9345