Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations

From: Santosh Chokhani <[email-masked]>
Date: Tue, 10 Apr 2001 17:30:26 -0400

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]]
Sent: Tuesday, April 10, 2001 5:26 PM
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, 

>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: "Anders Rundgren" <[email-masked]>
Date: Wed, 11 Apr 2001 09:59:39 +0200

RE: DoD Bridge Certification Authority Phase II DemonstrationsSantosh,
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.

You did not comment on all the drawbacks of using client-end-to-end encryption in an organization-
environment.

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.

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.

Anders
  ----- Original Message ----- 
  From: Santosh Chokhani 
  To: Anders Rundgren ; 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 
  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]] 
  Sent: Tuesday, April 10, 2001 5:26 PM 
  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, 

  >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. 

  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! 

  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