RE: Self-signed root transport and CA expiration

[Ned Smith <nsmith@xxxxxxxxxxxxxxxxxx>]

At 11:10 AM 11/20/96 -0500, Edward Russell wrote:
>Ned Smith (nsmith@ibeam.jf.intel.com) said on 11/19/96
>
>|||
>|||Have you considered the possibility of including the issuer public key in
>|||the subject's certificate? That way every certificate is a self-signed
>|||cert.
>|||Users(applications) that become reasonably familiar with any particular
>|||public key - and therefore trust it implicitly could choose not to verify to
>|||the root to obtain a self-signed cert.
>
>To which Ed Russell replies
>
>"Familiar with any particular public key" - How would I know whether it is
>the public key I am familiar with other than comparing the key itself or
>its fingerprint if you included that too with every CA public key I have 
>in my local store (or the set I am "familiar" with).
>
>Whether I check the signature of a certificate with a public key included in
>that certificate or with the public key in a certificate accompanying the
message,
>I still have to make sure that the key claiming to be the CA key is in fact
>the same key that I think is the CA key.

You have to do this regardles of whether the certificate contains the
issuer's public key or just the issuers DN. If the DN is provided then we
have to lookup the key from an external table before we can verify the
signature on the subject cert. If the issuer public key is provided then we
can verify the signature straight away. But we still must check to see if
the key is one we are familiar with, which equates to an external table
lookup. So the two approaches appear to be at least equal cost up to this point.

Yes I agree, the table of "familiar" keys should be updated according to
revocation messages issued by trusted CAs (who themselves likely would be on
the list).

If the number of keys the user is "familiar" with is small say 0-100 then
the lookup operation could be quite inexpensive. Using the other model,
every stage of the verification process requires every issuer DN in the
chain to also have an entry in the table. Otherwise, how would the verify
process know what key to use to verify the signature? This seems to imply
that the table potentially should have a DN/key entry for every public key
issued under the trusted domain. This could become a rather large table.
Plus this table must be kept consistent across all nodes performing
verfication checks (within the same domain). This seems to suggest some form
of distributed database or directory infrastructure is needed? My conjecture
is that the lookup costs of a large directory is larger than that of a small
one. Furthermore the majority of the costs of building and maintaining the
directory infrastructure must be paid upfront. 

If we assume the only way to get a cert chain is from the sender of a
message and the chain is comprised of self-signed certs, then a directory
service is not needed to verify the cert chain.

If we assume the cost of sending additional certificates with messages is
equal to the cost of maintaining consistent copies of a distributed
directory,  then the two approaches may very well have the same net cost in
terms of total computation and transmission.

However, the later (where every cert is a self-signed cert) does not first
require the deployment of the directory service before the verification
procedures can start operating. Interactions between principals in common
sub-domains could  send only the number of certs in the chain to get to the
common sub-domain (say intra-company messages). The unneeded part of the
chain above the sub-domain could be dropped since all principals are
familiar with the sub-domain key (and trust the sub-domain). This suggests
that the overhead of always needing to send the complete cert chain is not
mandatory.

Barring the mental gymnastics above, self-signed certs would make
bootstrapping a global certificate infrastructure more palatable IMHO.

Regards,
Ned

>
>Once I have accomplished that I have to make sure the CA key is valid in
the chain.
>I either do that by chasing it to the root, or flagging it as one I am
"familiar" with.
>However the familiarity bit must be 1. secured from being flipped without
my knowledge
>and 2. periodically rechecked since higher level CA certs may expire (I
guess they are 
>still valid in that case anyway) or even put onto a CRL 
>("Bribery Discovered at XYZ Cert Authority!!! - all certs suspect!")
>
>
>
>
>Edward Russell
>erussell@ftp.com
>
>
>
Ned Smith~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intel Architecture Labs  2111 N.E. 25th Ave.  Hillsboro, OR. 97124     
Ph: 503.264.2692 Fax: x1805  Email: mailto:nsmith@ibeam.intel.com   
http://www.intel.com/ial/security/index.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~