RE: Application form for agencies to apply to the FPKI PA

[Peter Hesse <pmhesse@cygnacom.com>]

Martin,

One of the goals of the FBCA is to minimize the impact on the client.  Most
client PKI applications were developed when LDAPv2 was around, and there was
no standard way to do referrals.  To this end, directories that did not
support chaining agreements could not be accessed with LDAPv2 clients.
Thus, the client is impacted.

Additionally, one may argue that client applications could be configured
with a list of LDAP directories to try when seeking information such as
certificates or CRLs.  This begins to impact the client as soon as a new CA
is cross-certified and a new directory needs to be added to the list.

A solution that required a large impact to the client, either at the outset
or when a new CA is cross-certified, is unacceptable for implementation
throughout the Federal due to the logistic and management problems it would
cause.

--Peter

---------------------------------------------------------------- 
Peter M. Hesse   pmhesse@cygnacom.com   http://www.cygnacom.com
      CygnaCom Solutions, An Entrust Technologies Company
      (703)848-0883(voice) (703)848-0960(fax) ICQ#1942828 
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius


-----Original Message-----
From: msmith@usitc.gov [mailto:msmith@usitc.gov]
Sent: Wednesday, May 17, 2000 3:56 PM
To: Multiple recipients of list
Subject: RE: Application form for agencies to apply to the FPKI PA 



Rich, Jim, etc--

I have been trying to understand for some time the exact technical issues 
that might keep LDAP-only servers (those that do NOT support DSP) from being

acceptable as agency border directories.  I haven't heard (or at least 
understood) a clear argument to that effect. 

Regardless, as a practical matter, smaller agencies are NOT going to buy
real 
X.500 border directories; they are going to use whatever directory
facilities 
they get for free with Win2000, Novell, Netscape or IBM/Lotus.  If 
participation by these agencies in a Federal PKI is desired, then the 
solution must work with LDAP-only servers.  (Or with an acceptable
outsourced 
option.)

Martin Smith


---------- Original Text ----------

From: "Heimberg, Jim" <Jim.Heimberg@GD-CS.COM>, on 5/17/00 1:34 PM:
To: iSMTP@MASTER7@ADP7["Multiple recipients of list" <pki-twg@nist.gov>]


Rich,
	Please keep in mind the problems the IETF-PKIX world is having with
the attribute certificates using LDAP and non-X.500 directories.  There may
be reason once the change is made to V3 Certs to have the capability to use
X.500 and DAP as required at least until the Attribute Certificate issue is
finally overcome.
Jim

-----Original Message-----
From: Richard.Guida@cio.treas.gov [mailto:Richard.Guida@cio.treas.gov]
Sent: Wednesday, May 17, 2000 1:12 PM
To: Multiple recipients of list
Subject: Re: Application form for agencies to apply to the FPKI PA for
interoperability - May 11 TWG meeting




Bill - far be it for me to quibble with the material below (I concur with
95% of it), but I do not believe our efforts require X.500 DSP.  True that
our demo employed DSP (chaining), but as we discussed, that was a function
of how the clients were designed; one could also have designed the clients
to use LDAP referrals - in essence burden them rather than the directory
system with finding cross-certs, ARLs, etc.  Because of that, I think that
we can well-define the responsibilities of the FPKIPA and the "application
form": (a) the form must provide the info required for the FPKIPA to do
policy mapping (no argument from anyone on that, correct?); (b) the form
should also provide the info required by the FPKIPA to ensure that the
applicant's directory system will not conflict with those who are already
using the FBCA - and by "conflict" I mean create any problems with chaining
among other agencies (where they have elected to use DSP); and (c) the form
should provide the info necessary for the FPKIPA to ensure that the
applicant has a workable mechanism (whether through DSP or LDAP with
referral) for directory access to support client use of the FBCA (i.e., the
ability to create and process trust paths).  Note that doing these things
does NOT require the FPKIPA to become the Directory Policy Authority
(although it would be nice if such an organization existed - that is a
separate debate) but rather just to provide enough info and guidance to
agencies so they can decide how to use the FBCA constructively - whether
through chaining or LDAP with referral.  I recognize this is a very
complicated area and warrants further discussion; we will definitely do so
at the Steering Committee meeting next Monday and I will attend the next
TWG where we can discuss it further.  But I think that the FPKIPA's job, at
its essence, is to: (a) policy-map; (b) ensure new members understand what
it takes to use the FBCA constructively; and (c) protect existing members
from harm as new members join.  Hope that is helpful -- Rich






Bill Burr <william.burr@nist.gov> on 05/17/2000 12:03:02 PM

To:   Richard.Guida@cio.treas.gov, pki-twg@nist.gov
cc:   mborzillo@fdic.gov
Fax to:
Subject:  Re: Application form for agencies to apply to the FPKI PA for
      interoperability - May 11 TWG meeting


Rich, Michelle and TWG participants,

I believe that the lesson of the BCA Demos is that to a first
approximation, PKI interoperability issues are directory/repository and
client issues.  The issues with the CA products s themselves are basically
workable, and comparatively straightforward.

The FBCA is as much about interoperability as about trust, so the FBCA
application should probably ask for information about interoperability,
that is largely about directories and clients.  These are not treated in
much depth in RFC 2527.

We have a directory CONOPS document, which describes the border directory
approach.  It at least pays lip service to a relatively universal directory
service, that embraces LDAP servers as well as X.500 DSA's, but it's short
on details about how to do that.  In the past year, this document has also
become a bit out of date WRT to who the current directory players are.

The BCA demo has been entirely an X.500 DSP based effort.  That is, all the
PKI's in the DEMO have an X.500 DSA that is chained to the BCA DSA.  That
works, but setting up the chaining in each case, was an adventure.
Moreover, in this architecture at least, the BCA DSA is a single point of
failure: if it's down the whole PKI is down.  Still, if we are to move
smartly into an initial operational BCA, I don't wee what choice we have
but to continue down this line.

A serious problem with the X.500 structure is that the naming space must be
managed and carefully partitioned.  X.500 DSAs will refuse to chain if they
don't agree about who is managing what part of the name space.  This is a
feature, not a bug, but without somebody to manage things and clear
guidance on naming, it's also a nightmare in a large diverse organization.

GSA at one point had stepped up to that plate, but the E-MAIL PMO that was
going to do it has gone away.  They have left a rather elaborate schema,
the USGOLD schema as a sort of orphan.  I have, the schema on the TWG
website and now Marion Royal just sent me the USGOLD design document, which
I have also put up on the website.  The old GSA USGOLD website no longer
seems to be operating.  I now think I have one of the big collections of
X.500 directory related documents anywhere on the TWG website.

In the mean time, Martin Smith has found a home for the Directory Forum
under the CIO Council, and is developing the "Federal White Pages"
directory based on LDAP protocols (at http://directory.gov.).  I find in
that my distinguished name is: uid=william.burr@nist.gov, ou=NIST,
ou=Department of Commerce, o=U.S. Government, c=US.  I presume that's
consistent with USGOLD.

Here in the PKI lab in the Security Technology Group at NIST we've become
tolerably comfortable with the PeerLogic (ICL) DSA, and familiar with it's
care and feeding.  But our operational services folks, who operate our
central services here at NIST, have a Netscape Directory Server that
they're comfortable with, and they plan to use for our NIST internal
directory and PKI.

As Martin Smith keeps reminding me, the market share of X.500 directory
products in this country, and in the Federal Government, is not
overwhelming.  Probably the most widely used directory product in the US is
the Novell NDS product, which doe not do DSP chaining.  The Netscape LDAP
server is popular, and, if WIN 2000 prospers, then Active Directory will as
well.  I think it's almost fair to say that WIN 2000 is built around Active
Directory.

So we have a de lemma: the only mature widely available, multi-vendor
directory technology that seems to work for us is X.500, but, by and large,
outside of DoD, our folks aren't using it very much.  We don't have a clear
manager for the government name space, and we don't have an official "root"
for a government wide X.500 directory.

Dave Fillingham has suggested that we need a directory profile.  I'll buy
that, but how do we create it?  We discussed this for a while at the May 11
TWG meeting.  The bottom line seems to be that we need to set up a
relatively small working group with directory savvy folks, to deal with
this.

Some questions: should the working group be a government (and direct
contractors) group, or would it be open to industry?  Do we have somebody
who is a directory person who wants to chair it? And is it acceptable to
come up with a strictly X.500 chaining approach, at least to start?

At any rate, I invite comments and opinions on this.  Until we know what
the directory ground rules are, I don't think that an Agency Application
form can add much value beyond the topics in RFC  2527.





At 11:46 PM 5/16/00 GMT, Richard.Guida@cio.treas.gov wrote:
>
>Bill/Michelle - my thinking about the points raised below has been that
the
>FPKIPA's function is to facilitate interoperability - which means more
than
>just performing policy mapping between the agency CP and the FBCA CP.  It
>also means (as Bill describes below) requiring some measure of directory
>interoperability, consistent/coherent name space control, etc.  In short,
I
>think the application form should: (a) require the applicant to describe
>its IT environment with sufficient specificity that the FPKIPA can make a
>judgment on whether there are any interoperability concerns with those
>agencies who are already interoperating with the FBCA (note that if we
>could just tell applicants what is needed to be interoperable, that would
>be preferable, but I suspect that will initially be unachievable, so I am
>proposing "full disclosure" which means that the FPKIPA will have to take
>the application, review it and then engage in some dialog with the agency
>in order to establish whether there are any problems; over time, however,
>we should adjust the application to specify what is needed for
>interoperability, and to the extent we can do that in part now, we should
>try - I just don't expect it); (b) propose a policy mapping between the
>agency CP and the FBCA CP, and the basis for the proposed mapping; (c)
>attach the agency's CP and agency CA CPS; (d) attach an independent
>third-party attestation that the agency is complying with its CP and CPS;
>and (e) describe how the agency will ensure it maintains configuration
>control over its PKI such that once the application is accepted, we can
all
>have confidence that no material changes will be made to its CP or CPS
>without the FPKIPA being advised.
>
>Then, in the Interagency Agreement between the agency and the FPKIPA (once
>cross-certing with the FBCA is approved), we need to capture the necessary
>information so that both parties (the agency and the FPKIPA) feel their
>interests are delineated and preserved.  I expect the IA to be more
>complicated and comprehensive, and as you know, we should try to devise a
>standard version that at least captures what we anticipate to be common
>among all of the IAs, leaving room for unique tailoring when needed.
>
>Hope those thoughts are helpful.  Final note: I am meeting with Gilligan
>and Holcomb next week and expect to have the FPKIPA officially established
>in June.  More to follow.  Very best regards -- Rich
>
>
>
>
>
>Bill Burr <william.burr@nist.gov>@nist.gov on 05/16/2000 05:35:15 PM
>
>Please respond to william.burr@nist.gov
>
>Sent by:  pki-twg@nist.gov
>
>
>To:   Multiple recipients of list <pki-twg@nist.gov>
>cc:
>Fax to:
>Subject:  Re: Application form for agencies to apply to the FPKI PA for
>      interoperability - May 11 TWG meeting
>
>
>
>Michelle,
>
>We had some discussion of this at the May 11 TWG meeting.  Our basic
>question is, what technical information do you see being involved in this
>application, other than that normally contained in the CPS?  The
>Chokhani-Ford CPS format is intended to be a systematic, consistent
>presentation of the information (both technical and nontechnical) that
>would be needed for a cross certification decision.  My impression is that
>it may satisfy the technical community better than the legal community in
>this respect, but I also have the impression that the ABA ISC is
attempting
>to address that.
>
>One answer might be that the application address some technical detail
>about directories (not dealt with in the CF outline), but this seems to me
>to be more a "cross-certification implementation detail" than a basic FPKI
>PA issue.  That is I tend to see the FPKI PA as making a decision about
the
>"quality" of an applicant PCA of agency PKI, and what policy level
mappings
>are appropriate, and directories to be more of a 'plumbing" issue, and not
>really an FPKI PA issue at all.
>
>Perhaps a consistent directory schema, and some required directory
services
>would be more than a plumbing issue. For example we might require that a
>domain must have a DSA offering LDAP, a standard schema, and be capable of
>chaining to the BCA directory. That's certainly how our demo works today.
>
>But there is a philosophical issue here.  Is cross-certification with the
>bridge only about trust, or must it also ensure directory and client to
>client interoperability?  That is, must a domain provide directory and
>other services that ensure interoperability with some "reference client"
>anywhere else in the FPKI?  With the best intentions in the world, we may
>initially have cases where a PCA cross certifies with the BCA, but many
>clients in some agencies are not capable of constructing certification
>paths from the available directory services, to all the end entity
>certificates in the overall FPKI.
>
>At any rate, I think that directories or repositories, and how clients can
>use them,  are the big practical technical issue remaining, but I'm not
>sure that they are a BCA cross-certification issue.  I'm not at all sure
if
>there are any issues here that can be handled in an application form.
>
>I think we need a better idea what technical issues would be covered in an
>application that are not dealt with in the CPS and the CF outline.
>
>Regards,
>
>Bill Burr
>
>
>>At 01:47 PM 05/01/2000 -0400, you wrote:
>>As we discussed, attached please find the portion of Rich's email that
>>describes his idea for the application form for agencies to use when
>seeking
>>to interoperate with the PA.  During our LPWG meeting last week, we
>>concluded for that this form will probably request a fair amount of
>>technical info from the applicant agency.  (I am cc'ing Mike O'Leary on
>>this, as he is covering for David Goldstone on the LPWG for the moment.)
>As
>>a matter of efficiency, the LPWG thought that the TWG would do a better
>job
>>of drafting the first draft, and then LPWG could review and comment.  The
>>TWG would probably know the types of technical info that ought to be
>>included in the application form that would enable the PA to make an
>>informed decision to approve or reject an application.  In any case, here
>is
>>the relevant part of Rich's email:
>>
>>         Second, per the discussion at the last Steering Committee
>>meeting, here is a list of the sorts of things which it would be helpful
>for
>>the Legal and Policy Working Group (LPWG) to begin to consider and
develop
>>in support of the FPKI Policy Authority, which I expect the CIO Council
to
>>support standing up this summer.  Please ensure you supply any input to
>>Michelle Borzillo (mborzillo@fdic.gov <mailto:mborzillo@fdic.gov> ) and
>>David Goldstone (david.goldstone@usdoj.gov)
>><mailto:david.goldstone@usdoj.gov)> , who are the co-chairs of the LPWG.
>>Michelle and David - once you have enough input to form a critical mass,
>>please proceed to deliberate on it with the LPWG.  Here are my
>suggestions:
>>1.  A notional application form which an agency can use to apply to the
>>Policy Authority for interoperability with the Federal Bridge CA.  This
>form
>>would include such things as: (a) a proposed mapping between the levels
of
>>assurance of certificates covered in the applicant agency's Certificate
>>Policy, and that of the FBCA, and justification for the proposed mapping;
>>(b) a description of the agency's directory structure and how it proposes
>to
>>ensure interoperability with the FBCA directory (e.g., LDAP, X.500, etc.,
>>and how namespace control is executed to ensure distinguished naming); +
a
>>description of the duties of the applicant agency including what auditing
>>results it must supply to demonstrate continued compliance with its own
CP
>>and CPS; and (d) a copy of the agency's CP and CPS for the principal CA
>>which it proposes to cross-cert with the FBCA.
>>
>>Please let me know what you think about this at your earliest
opportunity.
>>Thanks.
>>
>>Michelle Borzillo
>>(202)898-7400
>>
>>
>>
>Regards,
>
>Bill Burr
>
>
>
>
>
>
Regards,

Bill Burr