[Cryptography Team] Re: SSL Certificate Validation

[Cerebus]

On 1/25/07, Ron Teitelbaum <Ron at usmedrec.com> wrote:

> For example, there are systems for Hospitals, Doctors, Patients, Labs and
> ER's.  Each person has different access, but they also interact with
> different systems, so do you see a difference between coding authorization
> Permission on a Cert and using different CA's as the instrument that defines
> system access?

For a limited application--say, joining a WLAN--or a severely limited
but broadly available level of access--like getting to the front page
of a private web server--then mere possession of a certificate can be
sufficient authorization.  Anything beyond that and you want a
separation between authN and authZ.

In your case, if your user populations interact a lot then there's a
good case for having a single identity management system binding them
all together as a community.  Practically, this means a single PKI, or
at least a group of cross-certified PKIs (how ever, cross
certification has its own problem; path construction is a real PITA to
do right all the time in a cross-cert environment, and then there's
the whole namespace issue...).

So the cert provides identity proof, as it should.  Once you know
*who* the entity is, you need to define *what* the entity can do.
Simply put, the problem is this: authN is forever, but authZ is
temporary.  An entity's access rights can change at any time, for any
reason, from being fired to being promoted.  If that data is bound
*in* the cert, then you will have to revoke the cert whenever access
rights change.

Revocation is *bad*; it grows the CRL.  CRL growth causes problems.

The DoD PKI CRLs are over 140MB in the aggregate, and growing at a
prodigious rate--and that's only from the administrative revocations
(lost smartcards, name changes, rank changes, and affiliation changes
mostly).  If we had bound up access rights in the cert, the CRLs would
be terabytes in size.

> I understand the problems with coding system authorization and no CRL's, and
> I understand the maintenance issues with low level permissions but at a very
> high level I think it makes sense.

The separation of authN and authZ is one of the basic tenets of
information assurance, right up there with the Principle of Least
Privilege.

Start from base principles:  Identify the communities and define how
they interact.

If you're seriously building a PKI for your company I might be able to
set you up with business contacts with people who've done this for a
living.  Let me know off-list.

-- Tim