[Cryptography Team] Re: SSL Certificate Validation

[Cerebus]

Think about it this way:  If I show you my driver's license, would you
give me the key to your house?  Probably not; I don't belong in there.
 But *you* make the decision of who gets the key to your house, not
the state that issued the license.

-- Tim

On 1/26/07, Cerebus <cerebus2 at gmail.com> wrote:
> 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
>