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

[William.Flanigan@bmdo.osd.mil]

Hello Rich,

	My 3.0 cents worth (using the "Greenspan POV").  PKIs are really
just  databases and crypto tokens.  The stuff in between is not trivial, but
not show stoppers either (well, perhaps, PKI trust interoperability could
be).  The FBCA might "constructively address" the database end.  At the last
TWG, we kicked around something that seemed to smell like a "Federal Bridge
PKI Database Authority."  This might bridge at many levels including the
vendor level, the "chaining" level, and the hand-holding level.  Directory
databases are hard--there's only a bit more than a handful on the planet who
know how they REALLY work (or don't work).  Unlike policy, I feel that we
might want to consider helping rather than just citing take-it-or-leave-it
directory requirements for PKI bridging wantabees.  After all, I think we
all want to have a lot of traffic over that bridge.  Comments?  Flames? 

Best regards,

Bill 

-----Original Message-----
From: Richard.Guida@cio.treas.gov [mailto:Richard.Guida@cio.treas.gov]
Sent: Thursday, May 18, 2000 9:52 AM
To: Multiple recipients of list
Subject: RE: Application form for agencies to apply to the FPKI PA




Marion - thanks very much for your very helpful response.  This is exactly
the kind of dialog we need to have - appreciate your contributing to it.

I think the issue boils down to this: can we proceed to make the FBCA
useful for agencies to interoperate by helping them conform their
directories to a common approach, or do we have to stipulate that they must
do the latter before we allow interoperation with the FBCA (i.e.,
cross-cert with the FBCA)?  Just to state my view very clearly, I do not
think it is, or can be, the job of the FPKI Policy Authority to require
directory harmony.  That gets us into areas that far transcend PKI.
Rather, the Policy Authority can and should ensure agencies understand that
if they want to interoperate using the FBCA, we're happy to give them a
cross cert (after appropriate policy mapping) but they will also need to do
several things with their directories in order to use the functionality the
FBCA provides; those things include adhering to the schema/DIT elements you
articulated, employing X500 DSP in the backbone or using LDAP with
referrals depending upon how their client software is designed, etc.  I
would not agree that we should refuse an agency's application for an FBCA
cross-cert until they have proven to us that their client software and
directories are in a position to actually use the cross-cert usefully -
that is too intrusive in their business.  Now I would agree that an agency
would be very well advised to do all of this in tandem lest getting the
cross-cert becomes a useless act - but knowing how agencies operate, I can
easily see scenarios developing where one part of an agency goes after the
cross-cert (with an exquisite policy mapping), then once the cross-cert is
in hand, uses that fact to help compel changes to the directory system
(which, of course, is managed by someone else in the agency).

Those are my thoughts.  Let me assure you, however, that whatever the
Steering Committee decides, which could be more in line with your more
prescriptive approach, we will do.  These philosophical differences are far
from significant in the grander scheme of things.  Very best regards --
Rich





marion.royal@gsa.gov on 05/18/2000 09:09:58 AM

To:   Richard.Guida@cio.treas.gov
cc:   pki-twg@nist.gov
Fax to:
Subject:  RE: Application form for agencies to apply to the FPKI PA



Rich,

I will be unable to make the meeting on Monday and this is a critical
discussion, so I would like to offer a couple of comments.

1.  I think we all agree that (with current deployments of PKI), directory
interoperability is essential to the success of a Public Key
Infrastructure.
2.  The key to directory interoperability is a common schema (or perhaps
schemata) that establishes a naming convention and a definition of
technical objects that are specific to the infrastructure (hopefully, none
or very few that are not already defined by X.520 and other major schema
definitions.)
3.  GSA is still responsible for registration of names directly subordinate
to c=US, o=U.S. Government (though I'm not sure that the remnants of my
former office realize this.)  btw, ANSI is responsible for the c=US
namespace.
4.  Service level agreements are important amongst cooperating directories.
(This was one of the most important lessons learned in the EMA Directory
challenge)


I believe the statements above are true regardless of the choice of
directory protocol.  And there are probably other important statements that
are not occurring to me this morning.

I believe that the USGold Detailed Design should be reviewed by the TWG
with the intent of extracting everything useful and supplementing as
necessary to become a standing recommendation of the FBCA Policy Authority.
The USGold schema was used on an international level during the WEMA
challenge and it held up pretty well.  It did not introduce a lot of new
objects (less than 4, if I recall) but it did recognize the major schemata.
But, in my mind, the DIT structure and naming conventions described in the
document are straightforward and palatable to most agencies.  (The only
alternative would be to embrace the Domain Component naming convention for
distinguished names.)

The issue of X.500 vs LDAP (Didn't they win that war a long time ago?) will
have to evolve with the technology.  In a standalone PKI, LDAP works just
fine.  However, when you cross platforms, X.500 seems to be the only choice
in todays deployments.

The FBCA is successful because it contains multiple PKI Vendors in its
"membrane."  As PKI interoperability moves forward, the number of vendors
could effectively be reduced to one.
 I don't see why the FBCA considers directories, or at least certificate
validation any less of a responsibility.  Believe me, I understand the
challenges of trying to get a centralized/distributed directory in place.
If it was easy, it would already be done.  Martin also understands these
challenges, but from a different perspective (white pages.)

I believe that agencies deploying PKI should be prepared to invest in
whatever technology that is required to achieve interoperability (if that
is their goal.)  If it  means they must have a CA Directory that is not the
same as their corporate directory, so be it.  If their are methods to
exchange information between their CA Directory and their corporate
directory, fine.
If it is a single enterprise directory, nirvana.

I rarely disagree with you (in fact, this may be a first,)  but I believe
that the directory interoperability (or at lease certificate validation) is
a direct responsibility of the FBCA.  It should decide on a single
technology or provide architecture paths for alternative technologies....
just as it does with CA cross certification.

marion






Richard.Guida@cio.treas.gov@nist.gov on 05/17/2000 08:39:48 PM

Please respond to Richard.Guida@cio.treas.gov

Sent by:  pki-twg@nist.gov


To:   "Multiple recipients of list" <pki-twg@nist.gov>
cc:

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




Martin - the whole issue of directory services to support client software
use of the FBCA in creating and validating cert trust paths is something we
obviously need to have many further discussions on, within the TWG and
Steering Committee.  Let me offer the following two cents worth:

1.  Conceptually there is nothing that prevents client software from using
LDAP with referrals to create/process trust paths (e.g., discover certs and
CRLs).  Of course, such a client would be more complicated than the one
developed for the EMA Challenge (which used LDAP to the local DSA but
relied on DSP (chaining) among DSAs to obtain certs/CRLs), and arguably the
process would be less efficient.  E.g., there is a possibility that the
client would fail to be able to discover a trust path because referrals are
not deterministic but "probabilistic" in nature.

2.  There are ways to avoid this, including developing a "cert path
discovery/processing server" so that when the client gets a cert from an
external domain, it simply presents that cert to the server and the server
develops and processes a trust path - and is optimized to do so using LDAP
with referrals, or DSP, or whatever.  Lots of ways to optimize performance
here, including caching segments of trust paths that multiple clients may
find useful, etc.  This approach has a lot of appeal - avoids thick clients
and lots of client-side processing - but of course, it is just conjectural,
rather than the real stuff tested at EMA.

We need to decide what the FPKI Policy Authority should focus on
"regulating" - i.e., the FBCA, or the FBCA and directory services.  I am
personally of the view that the FPKI PA should regulate the FBCA and should
help agencies in getting their directory services effected so that clients
can use the FBCA, but that the FPKI PA cannot become the regulator of
directory services per se.  We should have a Federal Directory Policy
Authority for that purpose, but I realize that is a pipe dream.  My hope is
that agencies eager to interoperate using the FBCA will be driven to
conform directory practices, schemas, DITs, etc. for that purpose - but
again, I prefer the attraction to the compulsion model.  And ultimately, we
must support LDAP with referrals as well as X.500 DSP - even if the former
is not guaranteed to produce a trust path.  (We should provide the ability
to manually insert trust paths where they fail to be created
automatically.)

Hope that is helpful.  Separately, got your phone message; sorry for not
responding - in meetings all day today (so what else isn't new, right?).
Send me the phone number of the colleague you cited and I'll be happy to
call him as soon as I can.  Very best regards -- Rich





<msmith@usitc.gov> (Martin Smith)@nist.gov on 05/17/2000 03:55:44 PM

Please respond to msmith@usitc.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



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