Subject: RE: Update of RFC 2527 - opposed

From: Roger Younglove <[email-masked]>
Date: Fri, 22 Nov 2002 09:10:46 -0500

Well said Richard. Certification of a PKI should be done by an qualified
auditor following  the State of Washington's requirements. There must be a
CP and CPS in order to audit and certify a PKI.
 
Roger Younglove, CISSP

-----Original Message-----
From: Guida, Richard [JJCUS] [mailto:[email-masked]] 
Sent: Friday, November 22, 2002 5:20 AM
To: Terwilliger, Ann; [email-masked]
Subject: RE: Update of RFC 2527 - opposed
 
I strongly agree with Ann and separate comments made by Dave Fillingham.  At
Johnson & Johnson we have both a CP and a CPS to 2527, and intend to use
those not only internally (as we are already doing for our PKI which is
built and run internally) but also, when the time comes, to interoperate
externally.  Trying to negotiate external interoperability without a CP/CPS
to a common standard would be very cumbersome at best and is unlikely to be
satisfying.  I fully agree that any external interoperability will require a
contract; but the trick will be negotiating that contract and deciding what
to include in it.  One might wind up with a contract that looks like a CP -
in which case, why not start with the CP and include it as an addendum to
the contract?  In essence, the CP to 2527 becomes standard boilerplate for a
contract where you wish to have someone else accept your certificates.  Also
note that under a confidentiality agreement, I would expect to have to
expose the CPS as well to the party with whom we wish to contract - to give
them assurance that we are indeed running our PKI as our CP prescribes.
But even if we were never to interoperate (i.e., never ask anyone else to
accept our certificates, or seek to accept others' certificates ourselves),
the CP and CPS provide a comprehensive framework for running a PKI and are
invaluable for that purpose alone.  I do not accept the argument that what
an unknowledgeable auditor may or may not do should dictate what is
appropriate, we should proceed to do what is sensible and then defend that
and, where necessary, educate the auditor to understand and appreciate that.
Relationships with auditors should be at arms length - they do not have to
be adversarial.  My 1 1/2 cents worth.
 
Richard A. Guida 
Director, Information Security (Medical Devices and Diagnostics) 
Johnson & Johnson 
One J&J Plaza, Room WH6132 
New Brunswick, New Jersey  08933 
E-mail: [email-masked] 
Office:  732 524 3785 
 
-----Original Message----- 
From: Terwilliger, Ann [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, November 20, 2002 6:50 PM 
To: [email-masked] 
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, November 20, 2002 1:10 PM 
To: [email-masked] 
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

---

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

RE: Update of RFC 2527 - opposedA minor point:  I realize that the "State of Washington's requirements" was most likely meant as an example here, but I want to make it explicit.  The audit must be done following the requirements of whatever authority is controlling.  For example, a CA in Hong Kong must be audited to the requirements of the HKSAR Electronic Transactions Ordinance (ETO); they really don't give a rat's rear end about the "State of Washington".  :-) I suspect other jurisdictions and/or business regulators have similar views.

(Also:  I haven't looked at the Washington requirements in a few years, but in about 1998 or 1999 they had a couple of things I considered silly.  Is there a handy URL I can take a quick look at? Thanks.)

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

  ----- Original Message ----- 
  From: Roger Younglove 
  To: [email-masked] 
  Sent: Friday, November 22, 2002 9:10 AM
  Subject: RE: Update of RFC 2527 - opposed

  Well said Richard. Certification of a PKI should be done by an qualified auditor following  the State of Washington's requirements. There must be a CP and CPS in order to audit and certify a PKI.

  Roger Younglove, CISSP

  -----Original Message-----
  From: Guida, Richard [JJCUS] [mailto:[email-masked]] 
  Sent: Friday, November 22, 2002 5:20 AM
  To: Terwilliger, Ann; [email-masked]
  Subject: RE: Update of RFC 2527 - opposed

  I strongly agree with Ann and separate comments made by Dave Fillingham.  At Johnson & Johnson we have both a CP and a CPS to 2527, and intend to use those not only internally (as we are already doing for our PKI which is built and run internally) but also, when the time comes, to interoperate externally.  Trying to negotiate external interoperability without a CP/CPS to a common standard would be very cumbersome at best and is unlikely to be satisfying.  I fully agree that any external interoperability will require a contract; but the trick will be negotiating that contract and deciding what to include in it.  One might wind up with a contract that looks like a CP - in which case, why not start with the CP and include it as an addendum to the contract?  In essence, the CP to 2527 becomes standard boilerplate for a contract where you wish to have someone else accept your certificates.  Also note that under a confidentiality agreement, I would expect to have to expose the CPS as well to the party with whom we wish to contract - to give them assurance that we are indeed running our PKI as our CP prescribes.

  But even if we were never to interoperate (i.e., never ask anyone else to accept our certificates, or seek to accept others' certificates ourselves), the CP and CPS provide a comprehensive framework for running a PKI and are invaluable for that purpose alone.  I do not accept the argument that what an unknowledgeable auditor may or may not do should dictate what is appropriate, we should proceed to do what is sensible and then defend that and, where necessary, educate the auditor to understand and appreciate that.  Relationships with auditors should be at arms length - they do not have to be adversarial.  My 1 1/2 cents worth.

  Richard A. Guida 

  Johnson & Johnson 

  -----Original Message----- 
  From: Hicks, Mack [mailto:[email-masked]] 
  Sent: Wednesday, November 20, 2002 1:10 PM 
  To: [email-masked] 
  Subject: Update of RFC 2527 - opposed 

  Mack Hicks, SVP

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 25 Nov 2002 10:51:41 -0800

FYI all,

As many of you know, in March 2001 Carlisle, Stephen and I
proposed two OCSP-based services.  We called them Delegated Path
Validation (DPV) and Delegated Path Discovery (DPD).  That I-D
was allowed to lapse pending WG resolution of the DPV/DPD
requirements.  In Atlanta, I committed to the chairs to refresh
that I-D.

However, that I-D also addressed the separable need to expand
the certificate identification mechanisms.  This changed changed
core syntax, hence a v2 version number (i.e. OCSPv2).  To
complicate matters further, given that the original OCSPv2 I-D
was allowed to lapse, the certID/v2 issue has recently been
refreshed with yet another OCSP-based I-D that once more speaks
to v2-ness but also introduced yet another proposed
extension--the CRL Locator.

So to simplify matters for all of those in the WG that continue
to have the patience to review and comment on these things, two
new, unifying I-Ds are being produced and will be available
shortly.  This work will enable parallel and non-conflicting
consideration of the cert identification and DPV/DPD issues.

The first working document will be the "core".  It's primary
purpose is to enable consideration of alternative certificate
identification mechanisms.  It will propose a ReqCert syntax
that provides a CHOICE of: legacy-interoperable support for
2560's certID; full certificate (including ACs); the
CertIdWithSignature syntax as recently proposed; and
issuerAndSerialNumber as recently advocated by Peter Gutman.

The second working document will be a "Services and Extensions"
document.  It will include: the basic service of revocation
checking; all extensions as currently documented in 2560; the
new proposed CRL Locator extension; and the definition of DPV
and DPD services as originally proposed.  Thus, for OCSPv2, the
upcoming DPV/DPD question reduces to whether or not to retain
that related text in the S&E working document.

Following resolution of the DPV/DPD issue, both these working
documents will be reintegrated into a final I-D for WG last call
on what we want to call OCSPv2.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 26 Nov 2002 16:36:24 +0100

Mike,

My comments are embeded.

> issuerAndSerialNumber as recently advocated by Peter Gutman.

I don't think that it will include issuerAndSerialNumber as recently
advocated by Peter Gutman, since this form of identifier is insecure.

> checking; 

I don't think that it should include the basic service of revocation 
checking since this belongs to the core document.

> all extensions as currently documented in 2560; 

I don't think that it should include all extensions as currently
documented since they belong to the core document.

> the new proposed CRL Locator extension; 

I don't think that it should include the CRL Locator extension since it 
belongs to the core document.

 > and the definition of DPV  and DPD services as originally proposed.

I am (and have been) quite surprised to see that your proposal to expand 
OCSP v2 functionality is still there, since it has only be advertised to the 
list on November 15, i.e. the Friday before the Atlanta meeting, by Tim in 
the agenda, but not by yourself, prior to the meeting. :-(

> Thus, for OCSPv2, the upcoming DPV/DPD question reduces to whether 
 > or not to retain that related text in the S&E working document.

> on what we want to call OCSPv2.

Certainly not !

All people today know that OCSP means "on-line certificate status revocation
checking" as an alternative to CRLs, and not anything else. We are not going 
to change this.

Re-creating confusion once again with DPV or DPD would be very bad.

Everybody is not necessarilly interested by having more functionality.
If someone wants to comply with OCSP v2, it has to comply with the core
functionality. So extensions that are not related to certificate status
revocation checking, should not be placed in the core document.

The core document of OCSP v2 can progress to Draft Standard without
waiting the yet-to-be-written-"Services and Extensions" document.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 26 Nov 2002 08:07:54 -0800

Denis,

> I don't think that it will include issuerAndSerialNumber
> as recently advocated by Peter Gutman, since this form of
> identifier is insecure.

I'm pretty sure it will as a working document that attempts to
aggregate the inputs of all WG members who care to voice an
opinion.  Whether such technical content survives WG consensus
and WG last call is a totally separate matter.

I'm doing what I can to create a rough semblance of coherence.
In that regard, I'm most interested in the outcome of an open
discussion between you, Peter and others in the WG as to whether
or not issuerAndSerialNumber is an insecure form of certificate
identifier.  I do note that the S/MIME WG, from whom this syntax
is/will be imported, has gotten along fine with it.

> > Following resolution of the DPV/DPD issue, both
> > these working documents will be reintegrated
> > into a final I-D for WG last call on what we
> > want to call OCSPv2.
>
> Certainly not !

In general regarding the content of "core" vs. the "S&E" I-Ds,
keep in mind that I'm producing them to make it easy for the WG
to consider two parallel issues in a separable, non-contingent
manner.  Whatever comes of that consensus formation process
will, I'm planning, find it's way back into a single I-D.  If
however it turns out that it's best to keep them separate, I'm
happy to accomodate that collective view as well.

Mike

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 27 Nov 2002 00:02:18 +0100 (CET)

In message <[email-masked]> on Tue, 26 Nov 2002 16:36:24 +0100, Denis Pinkas <[email-masked]> said:

Denis.Pinkas> > The first working document will be the "core".  It's primary
Denis.Pinkas> > purpose is to enable consideration of alternative certificate
Denis.Pinkas> > identification mechanisms.  It will propose a ReqCert syntax
Denis.Pinkas> > that provides a CHOICE of: legacy-interoperable support for
Denis.Pinkas> > 2560's certID; full certificate (including ACs); the
Denis.Pinkas> > CertIdWithSignature syntax as recently proposed; and
Denis.Pinkas> > issuerAndSerialNumber as recently advocated by Peter Gutman.
Denis.Pinkas> 
Denis.Pinkas> I don't think that it will include issuerAndSerialNumber
Denis.Pinkas> as recently advocated by Peter Gutman, since this form
Denis.Pinkas> of identifier is insecure.

Except for the case when two different CAs have exactly the same DN,
I'm not really sure I see the problem with issuerAndSerialNumber,
except if things have been done around it that makes it insecure.

I don't recall exactly how OCSP is supposed to be handled re this, but  I
would imagine that having the request contain the issuerAndSerialNumber
plus a keyID would be enough to identify the requested certificate.
And if that is enough, perhaps one need to enforce such combinations
of information, or suffer the consequences of ambiguity (which I agree
with is insecure and possibly prone to forged answers)...

I believe that blaming issuerAndSerialNumber for lack of security is
missing the point.

If there are other cases that I can't currently see (it's 1am, and my
brain may not be as turned on as I believe), please inform me.  I have
no problem with standing corrected :-).

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"