Subject: SCVP and TRUST

From: Sal Mangiapane <[email-masked]>
Date: Thu, 09 Sep 2004 14:31:54 -0400

All,

This is a request to remove TRUST from SCVP and replace it with 
alternate mechanism(s) for server validation.

If you are willing to accept this idea and hear me out, then I believe I 
can provide the reasons to justify altering SCVP.

Two examples of trust mentioned in SCVP:
  1) end-user "client" device TRUSTing "SCVP server" (1.1 and 9.).
  2) "SCVP server" dealing with TRUST anchors (3.2.14 and 6.5).

As applied to the following solution:
   For example 1) computer-A would be "client" and computer-B would be 
"SCVP server".
   For example 2) computer-A would be an "SCVP server" and computer-B 
would be EITHER a "SCVP server" or a "CA server".

I propose a similar solution to both:
   A) IP address and network MASK limitations can be implemented so 
"computer-A" knows that "computer-B" is on the local lan or "computer-A" 
has been configured with the IP address of "computer-B".
   B) "computer-A" and "computer-B" have a shared secret key for mutual 
authentication.

Okay, if you are willing to accept that SCVP will be able to provide 
bi-directional mutual authentication using the solutions I provided or 
any other solutions.  Then, TRUST can be removed from the wording in SCVP.

WHY?

Let me build my case....  by example.... remember the early days of the 
internet when all naming was handled in HOST files?  And now, how DNS 
has revolutionized naming with on-line real-time name queries?  DNS 
naming is ubiquitous.

SCVP can be the same thing for PKI!  SCVP can move public keys from 
static files to on-line real-time queries!

As the use of public key technology increases, there will be more 
pressure on private keys and revocation lists.  Moving from regular 
updates to real time will only strengthen this technology.

Also, the accepted role of a CA will need to change.  The "monolithic CA 
providers" of today cannot provide the mutual authentication that I 
propose here.  CA servers would need to conform to a standard hierarchy. 
  The most obvious would be DNS naming.  Each domain owner would provide 
their own SCVP server.  I would see the role of "monolithic CA 
providers" changing from CA sources to service providers hosting SCVP 
servers and CA servers for the domain owners.

As the DNS has many roots, SCVP would have many roots and would use the 
same bi-directional mutual authentication to provide bridge arrangements 
to cross between top level domains.  On a side note, a TLD would provide 
the final authority for validating other TLD certificates.  So, one 
ccTLD can expressly reject certificates from another ccTLD.

I would also expect a change to the IP stack that would require the IP 
entry for it's SCVP server similar to DNS server entries.  I would 
expect the IP stack change would only occur if SCVP became widely accepted.

Now, what do the changes really give us?

Today, everyone expects DNS to be available and usable.  Because of 
that, it is widely used.  I believe SCVP will provide the framework, a 
universal hook, for other applications and protocols to easily and 
securely implement certificates and PKI.  Because of SCVP, PKI would 
become widely used.  I see immediate benefits for e-mail, VOIP, routing 
and DNS.  There are tremendous benefits with non-repudiation and IP 
spoofing prevention.  But, I'm preaching to the choir.....

Please respond,

Sal

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Sep 2004 17:19:18 -0400

At 2:31 PM -0400 9/9/04, Sal Mangiapane wrote:
>If you are willing to accept this idea and hear me out, then I 
>believe I can provide the reasons to justify altering SCVP.
>
>   For example 1) computer-A would be "client" and computer-B would 
>be "SCVP server".
>"computer-A" knows that "computer-B" is on the local lan or 
>"computer-A" has been configured with the IP address of "computer-B".

this is a seriously limited "security" mechanism and I don't think we 
should consider suggesting it as an effective way for the client to 
know that the SCVP server is "local."

>   B) "computer-A" and "computer-B" have a shared secret key for 
>mutual authentication.
>
>
>bi-directional mutual authentication using the solutions I provided 
>or any other solutions.  Then, TRUST can be removed from the wording 
>in SCVP.

"A" is not a viable solution. Were you suggesting that A and B be 
used together or were they both options?

>WHY?
>
>Let me build my case....  by example.... remember the early days of 
>the internet when all naming was handled in HOST files?  And now, 
>how DNS has revolutionized naming with on-line real-time name 
>queries?  DNS naming is ubiquitous.
>

SCVP addresses the problem of verifying certs, especially EE certs. 
but it does not address the problem of making these certs available 
to uses, so the analogy is not quite accurate.

>updates to real time will only strengthen this technology.

There is no implication that the revocation status data available to 
an SCVP server will be any more timely than what is available from 
use of CRLs or OCSP, so I do not see the rationale here.

>Also, the accepted role of a CA will need to change.  The 
>"monolithic CA providers" of today cannot provide the mutual 
>authentication that I propose here.  CA servers would need to 
>conform to a standard hierarchy.  The most obvious would be DNS 
>naming.  Each domain owner would provide their own SCVP server.  I 
>would see the role of "monolithic CA providers" changing from CA 
>sources to service providers hosting SCVP servers and CA servers for 
>the domain owners.

One can imagine aligning CAs with the DNS hierarchy, but the 
availability of SCVP is independent of this alignment.

>As the DNS has many roots, SCVP would have many roots and would use 
>the same bi-directional mutual authentication to provide bridge 
>arrangements to cross between top level domains.  On a side note, a 
>TLD would provide the final authority for validating other TLD 
>certificates.  So, one ccTLD can expressly reject certificates from 
>another ccTLD.

The DNS has a set of replicated, equivalent root servers. There is no 
requirement in SCVP for SCVP servers to be arranged in a hierarchy.

>I would also expect a change to the IP stack that would require the 
>IP entry for it's SCVP server similar to DNS server entries.  I 
>would expect the IP stack change would only occur if SCVP became 
>widely accepted.

When you suggest changes to the Ip stack I think it fair to say that 
you have gone rather far beyond the charter of this WG :-)

>that, it is widely used.  I believe SCVP will provide the framework, 
>a universal hook, for other applications and protocols to easily and 
>become widely used.  I see immediate benefits for e-mail, VOIP, 
>routing and DNS.  There are tremendous benefits with non-repudiation 
>and IP spoofing prevention.  But, I'm preaching to the choir.....

DNS is widely used because it is essential to accessing web sites, 
sending e-mail, etc. PKI is not necessary; it is an enhancement that 
enables security services, and these services are attractive to some, 
but not essential to all. Again, I think the analogy falls short.

Steve

---

From: Sal Mangiapane <[email-masked]>
Date: Thu, 09 Sep 2004 19:07:25 -0400

Stephen Kent wrote:
> should consider suggesting it as an effective way for the client to know 
> that the SCVP server is "local."
> 
> "A" is not a viable solution. Were you suggesting that A and B be used 
> together or were they both options?

Either.  With "A", I was thinking about NATed computers behind a firewall.

>> the internet when all naming was handled in HOST files?  And now, how 
>> DNS has revolutionized naming with on-line real-time name queries?  
>> DNS naming is ubiquitous.
>>
> SCVP addresses the problem of verifying certs, especially EE certs. but 
> it does not address the problem of making these certs available to uses, 
> so the analogy is not quite accurate.

Okay, comparing DNS to SCVP is a stretch. On a very simplistic basis 
they both respond to a question.  DNS answers "What is the IP address" 
and SCVP answers the "Is this cert valid".

I would suggest that the DNS response is only a tool that the client 
must make valuable for it's own use.  The client's application has to 
provide information in order to use the response.

> There is no implication that the revocation status data available to an 
> SCVP server will be any more timely than what is available from use of 
> CRLs or OCSP, so I do not see the rationale here.

Okay.

> 
>> Also, the accepted role of a CA will need to change.  The "monolithic 
>> CA providers" of today cannot provide the mutual authentication that I 
>> propose here.  CA servers would need to conform to a standard 
>> hierarchy.  The most obvious would be DNS naming.  Each domain owner 
>> would provide their own SCVP server.  I would see the role of 
>> "monolithic CA providers" changing from CA sources to service 
>> providers hosting SCVP servers and CA servers for the domain owners.
> 
> 

I agree completely.  SCVP has to be independent of DNS but SCVP can 
truly benefit with a parallel implementation.  The DNS independence is 
why I might eventually suggest manual IP address entry of an SCVP server 
as a required entry for IP configurations.

> requirement in SCVP for SCVP servers to be arranged in a hierarchy.

Agreed, SCVP would replace the equivalent root servers with a bridge 
authentication mechanism between TLDs.

> When you suggest changes to the Ip stack I think it fair to say that you 
> have gone rather far beyond the charter of this WG :-)

"stack" may not have been the correct phrase but I understand your point.

> but not essential to all. Again, I think the analogy falls short.

DNS was not necessary when it began -- something was needed.  It was 
well defined and good at it's designed task.  It was accepted and simple 
to use.

I believe that SCVP can be good enough at verifying certs that it too 
will become widely used.  I believe that the internet needs something to 
enable security services and PKI can really fill that need.  With SCVP, 
using certs will be simple, secure, consistent and readily available to 
any application.

I agree with you, this would not be essential but maybe email would use 
PKI and SCVP services to reduce SPAM.  Maybe VOIP (with ISP support) 
would use it for non-repudiated call origination.  The application would 
need to make it an essential service.  Rather than re-inventing the 
wheel applications and other WGs etc would begin adopting PKI and SCVP 
for internal and external benefits.

I do believe that the security for validating certs needs to go the last 
mile and include shared secret keys (or something) to the clients so the 
clients don't have to TRUST that the cert was validated by the proper 
authorities.

Sal