Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations

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

Anders:

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

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.

In my mind, depending on the business climate, one of the following offers
more advantages over the others and is hence appropriate:

Trust anchors list
Hierarchy
Bridge
Bilateral cross certification
Purple Model

ONE SHOE DOES NOT FIT ALL

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 1:00 PM
To: 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

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: "Anders Rundgren" <[email-masked]>
Date: Tue, 10 Apr 2001 23:25:53 +0200

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