Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations

From: Santosh Chokhani <[email-masked]>
Date: Tue, 10 Apr 2001 16:12:09 -0400

Larry:

1.  Trust between two clients is required regardless of the model.  It could
be explicit (cross certification) or indirect (Bridge CA).  The effort
involved is about the same.

2.  Bridge CA does NOT have combinatorial explosion since it scales
linearly.  N folks need N agreements with the Bridge as opposed to
n*(n-1)/2.

3.  Look at the purple model.  All it is doing is letting the organization
server sign the PO etc. as opposed to Purchasing Officer.  It is not
necessarily SSL.  We could argue as to how to tighten the server
authentication process.

-----Original Message-----
From: Frank Lawrence [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 1:41 PM
To: Anders Rundgren
Cc: Santosh Chokhani; Fillingham David W.; PKIX-List; 'KPCMWG'; 'DoD PKI
TWG'; [email-masked]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
FIREBURST USERS *; 'Steve Capps'; Wagner Clark J.;
[email-masked]; [email-masked]; 'Steve Hanna
(SUN)'; 'Susan Dernik'; Roger Younglove
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations

I will take a shot of the problem with the purple model.

The problem that I see with the Purple model is that there is a requirement
for
explicit trust between the "partners".  Known partners are nice but does not
solve
the broader problem of extending trust.

Works fine as long as the number of partners is small, but is
combinatorially
explosive as the number of partners becomes large.   The ability to manage
that
large number of trust relationships becomes just as difficult as the bridge
CA
problem.  The "unwieldy" PKI created by DoD elminates that problem, at least
within
DoD where there are hundreds (maybe thousands?) of "partner" domains.  At
least
within DoD there is an understanding of the level of trust involved in
getting a
certificate.

The current HTTPS model is a bad example of trust because there is no
(valid)
presumption of trust between a web server and a client.  SSL encrypts the
pipe but
there is no method for determining if the client or the server is who they
claim to
be.  Trivial to spoof either (or both) although the pipe is secure from
observation.  Even IPSEC based authentication (a step above the SSL model)
does not
provide any assurance that the claimed user is who they say they are.
Unless there
is a trust model that extends across the network, in a scalable manner, then
the
relying party is left holding the bag.

Finally, to trust a domain, you must understand how that domain issues
certificates.  If there is no policy which tells a relying party what the
level of
assurance is involved in the creation of the certificate, then the level of
trust
you place in that certificate is zero.

Anders Rundgren wrote:

> Roger,
>
> >IMHO, when you have multiple PKIs with in any industry such as the
> >Automotive (ie. ANX) or the Government, cross certification become a
> >problem because the certificate chain of trust becomes so unwieldy and
> >revocation of a PKI is also a problem. The Bridge scenario solves this
> >problem. It is not the only solution but the simplest with a number of
> >existing PKIs.
>
> Agreed, Bridge CAs solves (some of) the problems created by
> unwieldy PKIs such as those created by DoD.
>
> Domain-PKI does not requires such solutions as it is much simpler
> to create and maintain.  100 millions users of Internet use it today
> when they address an https URL.  That's simplicity IMHO.
> Applied to B2B it gets just slightly more complicated.
>
> Anders
>
> At 05:21 AM 04/10/2001 , Anders Rundgren wrote:
> >Santosh,
> >Domain (server-based) PKI offers persistent signatures for
non-repudiation
> >at a fraction
> >of the cost (and inconvenience) that inter-organization client-based
> >signatures introduce.
> >The need for bridge-CAs using domain-PKI is IMO very limited as the
number
> >of CAs is
> >reduced by several orders of magnitude by such approaches. 5-10 CAs
> >worldwide is my guess.
> >
> >I do have read the paper by Bill Burr. Did you read about Purple? I.e. do
> >you see a problem with this model?
> >
> >BTW, I am a (currently only lurking due to high work-load) member of the
> >OASIS Security Services TC where
> >domain-based solutions are standardized. I have never ever seen such an
> >enormous committee activity so domain
> >security is indeed red-hot.
> >
> >Internet2 with their Shibboleth distributed multi-campus authentication
> >system will be based on domain-PKI.
> >
> >Personally I expect the next version of OBI (Open Buying on the Internet)
> >to be entirely based
> >on this concept by throwing out the inter-organization client-certs (that
> >never worked, so just about
> >everybody turned to user-ID/passwords in spite of not being a part of the
> >standard).
> >
> >VISA's coming 3D Secure credit-card payment system is also based on
> >domain-PKI.
> >
> >Due to this, I think that DoD (and similar organizations all over the
> >globe) should very carefully evaluate the
> >domain security alternative before they do any new investments in CA
systems.
> >
> >Regards
> >Anders
> >----- Original Message -----
> >From: Santosh Chokhani
> >To: Anders Rundgren ; Fillingham, David W. ; PKIX-List ; 'KPCMWG' ; 'DoD
> >PKI TWG' ; [email-masked] ; 'Bridge CA Mail List' ; 'BCA
> >Integration' ; * ALL FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J.
> >; [email-masked] ;
> >[email-masked] ; 'Steve Hanna (SUN)' ; 'Susan Dernik'
> >Sent: Monday, April 09, 2001 22:39
> >Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >Anders:
> >I think Bridge technology can be helpful to a vertical segment such as
> >banking, health care, automotive industry etc. in order to
> >facilitate secure e-commerce among the trading partners where persistent
> >digital signature for non-repudiation may be required.
> >Also, given how organizations manage their Web sites and we hear about
Web
> >server break-in, persistent encryption (beyond SSL
> >transport) may call for interoperable, inter-domain PKI.  Again Bridge CA
> >can help.
> >Actually, I can see the benefits of layers (strata) of Bridge CAs, e.g.,
> >Bridge CAs from various vertical segments themselves
> >connecting to a Omni-Bridge.  In that case, the Bridge CAs will be
> >Principal CAs.
> >I assume you have had a chance to review the excellent paper on the
Bridge
> >concept developed by Bill Burr.
> >-----Original Message-----
> >From: Anders Rundgren [mailto:[email-masked]]
> >Sent: Monday, April 09, 2001 2:08 PM
> >To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI TWG';
> >[email-masked]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
> >FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
> >[email-masked]; [email-masked]; 'Steve Hanna
> >(SUN)'; 'Susan Dernik'
> >Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >David,
> >This is indeed an ambitious project. Unfortunately I doubt that the
Bridge
> >model has any relevance in
> >the private sector that for inter-organization communication, is more
> >likely to deploy domain-based
> >PKI-solutions, that have the major advantage of already being supported
by
> >global TTPs which makes
> >domain security solutions useful for organizations of any size. I.e.
> >VeriSign's issuance of web-server
> >certificates is "approximately" what is needed.
> >That domain security is incompatible with most current digital signature
> >laws is a pity.  Particularly for
> >the lawyers who created them.  :-)
> >Using domain security, tracing, message archiving, and user-control is
> >essentially built-in.
> >A further advantage of domain security models is that client security
> >solutions can develop in a
> >different pace at each organization.  As they have for current
> >Internet-banks that is so far the only
> >large-scale (almost) secure multi-organization transaction-environment on
> >the Internet.
> >The question that comes to my mind is: Will all Governments in the world
> >continue to adopt the
> >"All-speak-with-all-PKI" approach in spite of the fact that the private
> >sector probably have shunned it
> >due to complexity, privacy concerns, lack of control, and cost?
> >Regard
> >Anders Rundgren
> >X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com
> >
> >
> >
> >----- Original Message -----
> >From: Fillingham, David W.
> >To: [email-masked]' ; 'KPCMWG' ; 'DoD PKI TWG' ; [email-masked]' ;
> >'Bridge CA Mail List' ; 'BCA Integration' ; * ALL
> >FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ;
> >[email-masked]' ; [email-masked]' ; 'Steve
Hanna
> >(SUN)' ; 'Susan Dernik'
> >Sent: Friday, April 06, 2001 16:48
> >Subject: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >For the last few years, the National Security Agency has led the
> >development of Bridge Certification Authority (BCA) technology
> >demonstrations.  In 1999, Phase One of the Department of Defense BCA
> >Technology Demonstration showed the technical feasibility of
> >achieving signed e-mail interoperability using multi-vendor
> >cross-certification in conjunction with chained directory systems.
> >
> >Phase Two of the demonstration is now ready to be shown.  Phase Two of
the
> >DoD Bridge CA Phase II Technology Demonstration includes:
> >
> >Technologies:
> >
> >--  Certificate chain building in complex certificate graphs;
> >--  Integration of both mesh-style cross-certified PKIs and hierarchical
PKIs;
> >--  Multi-signature/hash algorithm processing in certificate chains;
> >--  Certificate acceptance/rejection based on Certificate Policy
> >processing, including policy mapping;
> >--  Transitive trust limitation using Name Constraints processing;
> >--  Access Control using X.509 compliant attribute certificates (same
> >attribute certificates used for e-mail and web based access
> >control);
> >--  E-mail access control using S/MIME V3 labeling;
> >--  E-mail encryption using public key certificates authenticated via a
> >Bridge Certification Authority;
> >--  Border Directories;
> >--  Multivendor directory interoperation via X.500 chaining; and,
> >--  Transparent sharing of certificate revocation information across
> >several  PKIs using products of multiple PKI vendors.
> >
> >Client Applications:
> >
> >--  Baltimore Technologies MailSecure enabled Microsoft Outlook
> >--  Entrust Enabled Microsoft Outlook
> >--  Getronics S/MIME Freeware Library, Certificate Management Library,
and
> >Access Control Library enabled Qualcomm Eudora
> >--  Getronics Certificate Management Library and Access Control Library
> >enabled Netscape Web Server
> >
> >Freeware Libraries:
> >
> >--  Cygnacom Certificate Path Development Library
> >      <http://www.cygnacom.com/products/index.htm>
> >--  Getronics S/MIME (Version 3) Freeware Library
> >      <http://www.getronicsgov.com/hot/sfl_home.htm>
> >--  Getronics Certificate Management Library
> >      <http://www.getronicsgov.com/hot/cml_home.htm>
> >-- Getronics Access Control Library
> >           <http://www.getronicsgov.com/hot/acl_home.htm>
> >CA vendor interoperability demonstrations:
> >
> >--  Baltimore Technologies
> >--  Entrust Technologies
> >--  Motorola
> >--  SPYRUS
> >
> >Directory Interoperability:
> >--  Entrust ICL
> >--  Entegrity Safepages Directory
> >Demonstrations will be held at the following locations and dates (note
> >that you MUST REGISTER to attend!  Registration information
> >is provided below):
> >
> >----------
> >CygnaCom
> >Suite 100 West
> >7927 Jones Branch Dr.
> >McLean, Virginia
> >
> >Directions to CygnaCom are located
> >at:  <http://www.cygnacom.com/contact/directions.htm>
> >
> >26 April 2001 - 0900
> >
> >26 April 2001 - 1300
> >
> >16 May 2001 - 0900
> >
> >16 May 2001 - 1300
> >
> >---------
> >Getronics Government Solutions
> >141 National Business Parkway, Suite 210
> >Annapolis Junction, Maryland
> >
> > From Washington DC: Take I-95 north; take MD Rt 32 east exit; take
Dorsey
> >Run exit; at stop sign turn left on Dorsey Run; at stop light turn right
on
> >Guilford Road which becomes National Business Pkwy.
> >
> > From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit;
stay
> >in right lane of the exit which runs into National Business Pkwy; make a
> >right on National Business Pkwy.
> >
> >30 April 2001 - 1300
> >
> >8 May 2001 - 0900
> >
> >8 May 2001 - 1300
> >
> >24 May 2001 - 0900
> >
> >24 May 2001 - 1300
> >
> >---------
> >
> >All showings last about half a day - with a mixture of conference room
> >briefings and laboratory demonstrations.
> >
> >We are limited by available demonstration space to an absolute maximum of
> >20 participants at each showing.
> >
> >IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([email-masked]
> ><mailto:[email-masked]>) AND MYSELF
> >([email-masked] <mailto:[email-masked]>) IF YOU PLAN TO
> >ATTEND.  IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE
> >ADMITTED TO THE DEMONSTRATION.
> >
> >Please provide the following information to register:
> >
> >--  Name
> >--  Organization
> >--  E-mail address
> >--  Date and time of the demonstration showing you wish to attend (with
> >alternates, if possible)
> >
> >We look forward to seeing you at the demonstration!
> >
> >Dave Fillingham
> >NSA
>
> --------
> TTFN
> Roger W. Younglove, CISSP
> Distinguished Member of Consulting Staff
> Lucent Worldwide Services--Information Security
> 100 Galleria Officentre, Ste. 220
> Southfield, MI 48034-8428
> Numeric page: 888.935.6755
> E-mail page:
> [email-masked]
> eFax number: 413.425.5368
> www.lucent.com/netcare

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 11 Apr 2001 11:23:12 -0400

Anders: See comments in-line.  I suggest that we take this off-line and not
waste others' time.
 
All: I am sorry for this rambling. 
 
-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, April 11, 2001 4:00 AM
To: Santosh Chokhani; Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI
TWG'; [email-masked]; 'Bridge CA Mail List'; 'BCA Integration'; 'Steve
Capps'; Wagner, Clark J.; [email-masked];
[email-masked]; 'Steve Hanna (SUN)'; 'Susan Dernik';
Roger Younglove
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations

Santosh,
I do understand this. But assume that your customers have so far not been
aware of alternatives?
To say that they cannot accept intermediaries is like saying "we do not
trust file-servers".  That's
a rather extreme position.  Many organizations live or die depending on how
their "intermediaries" work.
[Santosh Chokhani] There is a deference in availability of service and
trusting confidentiality and integrity provided by a service.
 
You did not comment on all the drawbacks of using client-end-to-end
encryption in an organization-
environment.
[Santosh Chokhani] Each option has its benefits and drawbacks and that is
why we have so many architectures and products with different approaches. 
 
If a project group involves very few people (two lawyers on the same case)
that have exclusive
rights to their information the situation may call for end-to-end
encryption.
[Santosh Chokhani] We need end-end encryption and authentication many times.

I.e. domain-PKI is definitely not only about security, but about who is in
control (i.e. owns and is
responsible for the information).  If DoD builds on a model where the
individual is the owner,
I think that they pretty soon will get severe problems, as lost private keys
can lead to information-
loss in a way the paper-world have never seen.  Then we are into key
backup-schemes that
if applied to individuals is a major problem.  Applied to domain-PKI it is
*almost* reasonable.
[Santosh Chokhani] Lost private keys are not a problem if key recovery is
properly implemented.  Please note that you do not need to recover signature
private keys since once they are used for signing they are not required for
verification.  Just like gravity, we tend to sign before verifying the
signature.
 
Anders

----- Original Message ----- 
From: Santosh  <mailto:[email-masked]> Chokhani 
To: Anders  <mailto:[email-masked]> Rundgren ; Santosh Chokhani
<mailto:[email-masked]>  ; Fillingham,
<mailto:[email-masked]> David W. ; PKIX-List
<mailto:[email-masked]>  ; 'KPCMWG' <mailto:[email-masked]>  ; 'DoD PKI
TWG' <mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  ; 'Bridge CA Mail  <mailto:[email-masked]>
List' ; 'BCA Integration' <mailto:[email-masked]>  ; 'Steve
<mailto:[email-masked]> Capps' ; Wagner, Clark J.
<mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  ; 'Steve Hanna
<mailto:[email-masked]> (SUN)' ; 'Susan Dernik'
<mailto:[email-masked]>  ; Roger  <mailto:[email-masked]>
Younglove 
Sent: Tuesday, April 10, 2001 23:30
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations

Anders: 

I do not think you understand this.  My customers do not want intermediate
systems except the people working on the project to access the data.

-----Original Message----- 
From: Anders Rundgren [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, April 10, 2001 5:26 PM 
To: Santosh Chokhani; Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD 
PKI TWG'; [email-masked] <mailto:[email-masked]> ; 'Bridge CA Mail
List'; 'BCA Integration'; 
'Steve Capps'; Wagner, Clark J.; [email-masked]
<mailto:[email-masked]> ; 
[email-masked] <mailto:[email-masked]>
; 'Steve Hanna (SUN)'; 'Susan Dernik'; 
Roger Younglove 
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations 

Santosh, 

>Having looked at the papers you sent, I think your solutions may be ok as a
B2B solution. 

I believe so. 

>But, I see end to end security requiring PKI. Even in our company's case
where 
>we run independent labs, do PKI consulting and build PKI products, some of
our lab 
>customers when they send us documents over the Internet, they want only the
lab 
>personnel assigned to the project to read it. They do it using end-end
encryption. 
>PKI concepts were designed for this distributed, client centric model. 

Even in this example you have conflicts with different interests that may
suggest that 
a domain-solution could fit as well. Assume that more than one individual is

supposed to be able to access the sent document. In that case it would be
more 
appropriate to encrypt using a domain public key and let the receiver's
local client file access 
system direct who is going to have access to the document. Otherwise it
looks 
like this document is not a part of some organization's activity and in that
case 
domain-PKI does of course not apply. In the senders end it may be in the 
organization's interests to monitor all outgoing documents. That is in
conflict 
with the client doing the encryption. 

And the very same problem is also valid for archiving of signed data from
authorities. 
Using domain-PKI you get it for free. Using client-PKI (only) you get less 
control which is bad as control probably was the reason for adding PKI in
the first place! 

And now the heat is on directories... 

An interesting side-effect of Purple-type of solutions is that [more or
less] public directories 
holding information about employees become largely superfluous as all
information required 
for a certain relation is in the tickets themselves.  I.e. purchaser
"profile" information is a 
typical item that now finally have gotten a suitable container to be
transported in. 

/anders

---

From: "Friedrichs, Paul LCDR" <[email-masked]>
Date: Wed, 11 Apr 2001 13:15:57 -0400

HI All,
 
Fascinating thread. I wonder whether we are confusing application and
credential architectures. I think this is how I see it. Perhaps I'm missing
something. (Or perhaps I'm totally naive): 
 
Application architectures need to address who/what must, might or must not
know the existence of whom/what, and who/what trusts whom/what for what
purpose. (Perhaps only people should be said to "trust" and so "rely on"
might be a better word, but the differences and relationship between trust
and reliance shouldn't be overlooked.) Notions of authorities, officers, and
agents must be addressed by the application architecture. Nonrepudiation and
confidentiality are very different application requirements that may require
very different application architectures (and subjects).
 
Credentials can be issued to subjects required by application architectures
(e.g., to individuals and agents/organizations). 
 
Except, perhaps, when considering nation states, the trustworthiness of
signature credentials should be able to be abstracted from the trust between
subjects. Signature credentials need to be trustworthy and of
comparable/known trustworthiness (only) across the subjects with whom
subjects wish to securely interact. Perhaps this is an excellent place for a
government service. (The US's Privacy Act is a *BIG* challenge when
statically naming private citizens.) (Another thought is that where the
existence of subjects is known only locally, locally managed signature
credentials are likely most efficient.) Signature credential architectures
wishing to support wide interoperability should be able to focus on
addressing the core challenge of the commonness of the credentials' strength
(not who trusts whom). The best mix of signature credential architecture
options will depend on what sorts of signature credential service providers
succeed in the marketplace.  
 
Because of the possibility of and frequent requirement for data recovery,
the encryption credential seems to be a very different challenge. Perhaps it
will always be best for trust domains to issue their own encryption
credentials, suggesting that a different credential architecture mix will be
required. 
 
I think the application, signature credential, and encryption credential
challenges/architectures are independent.
 
Paul

---

From: "Fillingham, David W." <[email-masked]>
Date: Wed, 25 Apr 2001 13:00:07 -0400

This is a reminder that showings of the Department of Defense Bridge
Certification Authority Technology Demonstration will begin tomorrow.  There
are about 110 open slots (total) for those who would like to view one of our
nine scheduled demonstrations.

If you have already registered for the demonstration, you should have
received an e-mail confirmation that you have been registered.  A network
failure here on 6 - 9 April may have prevented some of your registration
requests from being received.  If you did not receive an e-mail
confirmation, please re-register.

Demonstration dates, times, directions, and registration instructions are
included below.

Dave Fillingham
NSA

> Sent:	Friday, April 06, 2001 10:49 AM
> To:	[email-masked]'; 'KPCMWG'; 'DoD PKI TWG'; [email-masked]';
> 'Bridge CA Mail List'; 'BCA Integration'; * ALL FIREBURST USERS *; 'Steve
> Capps'; Wagner, Clark J.; [email-masked]';
> [email-masked]'; 'Steve Hanna (SUN)'; 'Susan Dernik'
> Technology Demonstration showed the technical feasibility of achieving
> signed e-mail interoperability using multi-vendor cross-certification in
> conjunction with chained directory systems.
>  
> Phase Two of the demonstration is now ready to be shown.  Phase Two of the
> attribute certificates used for e-mail and web based access control);
> --  Getronics S/MIME Freeware Library, Certificate Management Library, and
> that you MUST REGISTER to attend!  Registration information is provided
> below):
>  
> ----------
> CygnaCom
> Suite 100 West
> 7927 Jones Branch Dr.
> McLean, Virginia
>  
> Directions to CygnaCom are located at:
> <http://www.cygnacom.com/contact/directions.htm> 
>  
> 26 April 2001 - 0900
>  
> 26 April 2001 - 1300
>  
> 16 May 2001 - 0900
>  
> 16 May 2001 - 1300
>  
> ---------
> From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey
> From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay
> <mailto:[email-masked]>) AND MYSELF ([email-masked]
> <mailto:[email-masked]>) IF YOU PLAN TO ATTEND.  IF YOU DO NOT
> REGISTER TO ATTEND, YOU WILL NOT BE ADMITTED TO THE DEMONSTRATION.
>