Subject: Why do attr. cert. lifetimes matter?,was Example with sub-attributes

From: "Bob Blakley" <[email-masked]>
Date: Wed, 19 May 1999 14:26:55 -0500

Thanks to Ed for the dialog; nice to lurk a bit & have the flag still flying.

Bob,

>Ed,
>
>There must be a pony in here somewhere, but other than an interesting
>mathematical exercise, I'm not sure that I can put my finger on it yet.
>
>What I'm groping for is something that would tie the expected
>certificate lifetime back to a useful cost measure, I.e.,

My initial motivation in looking at this statistic was to figure out what
percentage
of the time attribute certificates would be revoked for reasons having nothing
to do with the validity of the attributes on the basis of which an
authorization decision
would be made.

Hmmm... since that sentence is too long, how about an example?  Let's say my
attribute
certificate is my business card (I use this example in talks...).  Let's say
furthermore that
what I'm trying to do is download a copy of the Kerberos source code (with
crypto) from MIT.
The server is going to check my domain name to make sure I'm a "real
American".
But when it looks at my attribute certificate, it might reject it for a number
of extraneous
reasons:

        1.         It's been revoked because my department number changed
        2.         It's been revoked because my name changed
        3..n.     etc...
        n+1.    The server doesn't trust my CA
        n+2.     My CA didn't pay its bill with a cross-certifying agent, so
it's cert has been revoked
        ...         (anyone think of any others?)

None of these has any bearing on whether I'm presenting a valid domain name
for the purposes
of authorization, so a rejection for most of these reasons certainly counts as
a "false positive".
I want to know how often false positives are going to come up if we put
attribute certificates
into use in operational authorization systems, which is why the mean useful
lifetime of
attribute certificates is of interest to me.

>1.  You should use individual attribute certificates rather than
>compound attribute identity certificates if X>Y, for suitable values of
>X and Y??

Essentially this is what I'm getting at in the narrative above.

>2.  If certificate retrieval costs X, the cost of incorrectly relying on
>an revoked certificate for some transaction is Y, and the time s
>since the certificate was last validated by CL or OCSP checking is T,
>then you should/should not revalidate the certificate??

Interesting, but not what I had in mind.

>Any thoughts as to where this can take us?

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

From: Ed Gerck <[email-masked]>
Date: Wed, 19 May 1999 22:01:31 -0700

> Thanks to Ed for the dialog; nice to lurk a bit & have the flag still flying.

I think we have exceeded the math limit on lists, but what is claim
without proof?

> percentage of the time attribute certificates would be revoked for reasons
> having nothing to do with the validity of the attributes on the basis of which
> an authorization decision would be made.

Yes, in general any certificate (ie, even an identity certificate) is revoked not
because *everything* in it is wrong but because at least *one* item is wrong.
Thus, the question applies to any certificate -- but especially to attribute
certificates because the probability for at least one item to be wrong should
expectedly increase with the number of items.

....

> None of these has any bearing on whether I'm presenting a valid domain
> name for the purposes of authorization, so a rejection for most of these
> reasons certainly counts as a "false positive".

Yes. The certificate was revoked for a "false" reason -- since that reason was
not relevant to the revocation need for the case at hand.

I note that one of the strong reasons for certificate rejection is when it is
expired, but this can also be a "false positive" -- and expired certificates
can still be useful and valid for all information they contain. An example
I like to use is that an expired driver's license should still allow you to
be identified when cashing a cheque. Another example is that an expired
CA certificate is the only way to allow a new CA certificate to be certified
if it was not introduced before the expiration. There are other examples
of this time logic -- as when you sent a message before your certificate
expires but it is only read after it expires. And yet, the case "expired but
not revoked" is usually not properly handled by certification applications.

> attribute certificates into use in operational authorization systems, which is
> why the mean useful lifetime of attribute certificates is of interest to me.

Yes, but even if you expect no false positives (suppose, *all* information
is needed, not only that which may cause a revocation), it is useful to estimate
the lifetime of certificates in order to properly manage them and their revocation
needs.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [email-masked]