> the idea of setting up a server that everyone in the world would trust was
> suggested in RFC 1422 (IPRA), in 1993.
> It did not succeed terribly well then, and people have tended to look very
> skeptically upon ideas that require some sort of "single root" since then.
>
> What's your reason to believe it could succeed this time?
>
The short answer; I'm not sure. A PKI system is technically a good mechanism
to provide non-repudiation. I think there is tremendous benefit in non-
repudiation which makes it worth while. Non-repudiation is all that I'm
suggesting.
The long long long answer (forgive the lengthy answer :)
Some differences to this proposal(CAS) compared to RFC 1422:
1422: Based upon X.500 naming convention which is not in general use.
CAS : Based upon DNS naming convention which in foundational to internet use.
1422: Use PKI to validate foreign users. Foreign being email addresses in a
different domain, the RCPT TO address.
CAS : Require data privacy. The first SMTP server MUST verify the MAIL FROM
the last SMTP server MUST verify the RCPT TO. Every SMTP would append
a digital signature.
1422: Single root the IPRA.
CAS : Each TLD would be the root of it's tree very similar to DNS today. The
bridging certificates are provided as a service so a server with a name
ending in COM could trust a server with a name ending in NET.
1422: Use PKI to encrypt messages.
CAS : MAY use PKI to encrypt messages. This is not part of the requirement
for a CAS system. It is a feature of PKI that could be used.
1422: IPRA is certifying body and provider of certificates.
CAS : Each domain would provide it's own certificates. Let me explain how
I see this implemented because this is where (I think) the scalability
and biggest differences comes in.
There would be a CAS record in DNS to designate the authoritative CAS server.
This server would own all certificates for it's domain (example.com). Every
domain owner would be REQUIRED to have a CAS server just like every domain
owner is REQUIRED to have a DNS server. The hierarchy just manages the trust.
COM would provide certificate for EXAMPLE. EXAMPLE would provide
certificates for WWW, MAIL, LDAP, whatever... I would suggest that each email
address could have a certificate too. The com.user@xxxxxxxxxxx certificate
would be managed by CAS server for EXAMPLE.COM too.
In order to send "trusted" email from com.user@xxxxxxxxxxx to
net.user@xxxxxxxxxxx the MAIL.EXAMPLE.COM would 1)verify com.user@xxxxxxxxxxx
with or without a certificate, 2)sign the email and 3) forward it
to MAIL.EXAMPLE.NET. MAIL.EXAMPLE.NET would 1) verify net.user@xxxxxxxxxxx
2) query it's own CAS server which would recursively query CAS servers up
the NET tree across the bridge and back down the COM tree to EXAMPLE.COM
CAS server. The CAS server would then pass the public key to
MAIL.EXAMPLE.NET so it could verify the signature from MAIL.EXAMPLE.COM and
accept the email, and 3) sign the email, and finally 4) forward the email to
net.user@xxxxxxxxxxxx
The CAS servers would rely upon DNS for resolving IP addresses as you would
expect. But, I would recommend that CAS IP address would be REQUIRED as
manual entry similar to the default gateway and DNS server entries. I do not
believe that DNS can provide trust by itself. I do not believe that CAS can
provide trust by itself. Both the DNS and the additional setting for CAS IP
address would be required to provide independent path for auditing. You
can't have one server that just provided you an answer to verify itself,
because any attack to compromise a server could and would authenticate
itself. At least two servers (DNS and CAS) would need to be compromised to
successfully complete an attack.
Also, I would expect two types of CAS servers. One being the authoritative
CAS server for authoritative public keys. The other being resolving CAS
server for querying (and cache-ing) public key answers. Note, resolving CAS
servers would need to be simple to implement but also need to be uniquely
named. I believe there would be trust assumptions possible for Private-use
networks(as defined in RFC 3330) that also mask to a local address.
Also, each entity could have multiple key pairs. I see the need for 1)single
use and 2)limited timestamp certificates. For example, com.user has web
based access to email. When working from the office com.user would have an
established PKI. Planning for vacation or business trip, com.user would
create a set of key pairs with a timestamp for each day. So entering a
private key on an untrusted computer would only cause limited damage. A
single use key may also work in this situation. The private keys could be
stored on some device like a san disk or floppy disk.
Also, PKI needs some assistance for initially establishing authenticity. I
would propose using Shared Secret Keys(SSK). Because certificates can be
revoked additional overhead would be required to rely upon PKI for initial
startup. So, each internet based server(IBS) would be REQUIRED to have an SSK
with it's resolving CAS server. There might be multiple CAS servers, just
like DNS, but the number of servers would be manageable. Exceptions for
omitting the SSK MAY be provided for private-use networks (as described in
RFC 3330). The SSK would need to be entered via some out-of-band method.
The IBS would have to know 1)it's own private key 2)the shared secret key and
3)the CAS IP address. The resolving CAS server would have to know 1)the IBS
public key and 2)the shared secret key. Upon IBS startup, it would query the
CAS providing it's public key. The CAS would respond with 1)the SSK and
2)the CAS (it's own) public key. The CAS would encrypt these with the IBS
public key. The IBS would decrypt the message and verify the SSK. The IBS
would have a trusted CAS public key! All public servers including CAS
servers would have to include this extra step during startup.
Also, CAS could be used for SERVER-A to directly establish a PKI trust with
SERVER-B. This could be used for B2B or legal type transactions. SERVER-A
and SERVER-B would have to self maintain this key pair for their trust
relationship it would not be maintained by the CAS system. This would be a
business decision and would require some command to initiate this trust
transaction. The business server only needs to know the FQDN to setup the
trust because it could rely upon CAS to initially establish the trust. This
would truly help prevent MiTM attacks.
If you are reading this, I may actually have an implementation that merits
further review. Thanks for your inquiry.
Best Regards,
Sal
Salvatore Mangiapane
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf