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

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 20 May 1999 05:55:39 +0100

Bob,
comments in line

<snip>

>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?)
>

I have a few questions and comments to this.

Did you present an AC without the corresponding authenticated PKC?
If so I wonder if the scenario is valid at all as the AC could be stolen.

In my vision ACs of this kind (organization-oriented), should only be used in conjunction
with an authenticated organization PKC and the AC should be fabricated on-the-fly by the former.

Then (using my maybe naive thinking) there is no need for CAs, revocation, CRLs or OCSPs for ACs.  Only for PKCs. 
And PKCs are typically issued by TTPs and therefore none of the listed issues apply.

<snip>

http://www.mobilephones-tng.com/v100/dynamiccerts.html

Regards
Anders Rundgren

---

From: "Bob Blakley" <[email-masked]>
Date: Thu, 20 May 1999 08:53:39 -0500

Anders,

>If so I wonder if the scenario is valid at all as the AC could be stolen.

No; I just left out the PKC discussion (took it as assumed) in the interest of
focusing on the main point.

>with an authenticated organization PKC and the AC should be fabricated
on-the-fly by the former.

This is one scenario, but it's certainly also plausible that you could get
ONLY an AC, for example
in cases involving role-based authorization where you want to authenticate the
user and then
assert a role but not the primary identity (this might be important for
privacy reasons, e.g.)

>And PKCs are typically issued by TTPs and therefore none of the listed issues
apply.

I don't get this at all!  How does the relying party know *when* the
organization's CA fabricated
the AC?  And why use a cert. for this at all -- after all, Public-Key
operations are expensive compared
to other ways of doing what is essentially first-party trust.

--bob

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 20 May 1999 21:15:46 +0100

Bob,

<snip>
>assert a role but not the primary identity (this might be important for

Sorry, I don't understand how this works.  How do authentication with key-less certs?

>organization's CA fabricated the AC?

Well, maybe we should not talk about CA when it is really as signed message object in
the form of an AC?

>And why use a cert. for this at all -- after all, Public-Key

You are right!  You have just invented the "crippled AC" that just contains the
validity-time and attributes.  There could be some value in keeping the format
compatible with other ACs though.  

regards
Anders

---

From: "Bob Blakley" <[email-masked]>
Date: Fri, 21 May 1999 13:29:48 -0500

Anders,

Thanks for your note.

>Sorry, I don't understand how this works.  How do authentication with
key-less certs?

Ah!  This is where we've not been communicating.  I'm presuming that keyless
attribute
certs are NOT used for authentication; they're used to assert a third-party
view of
the attributes of the possessor.

Authentication would be done using a keyed cert., and the keyless attribute
cert, which
might or might not contain the distinguished name as a link back to the
authentication
cert., would be transmitted within the authenticated communication
susequently.

The point here is that the authority asserting the attributes may be
*different* from
the one asserting principal names; indeed many authorities may assert
attributes about the
same principal name.  The authentication operation establishes the principal
name by
showing possession of the private key matching the "identity cert" (not really
any such thing,
of course - it's really just a name cert).  Then a subsequent operation (AC
verification)
establishes attributes, based on the assumption that the principal name is
correct.

>>>And PKCs are typically issued by TTPs and therefore none of the listed
issues
>compatible with other ACs though.

Is this really an invention of mine?  Hmmm...

My notion here is that there's a *credential*, which is just a packet of
attributes,
and an AC, which is formed by adding a lifetime, serial number, and some other
housekeeping stuff to the credential and then signing the result.

If all the housekeeping stuff (signature, lifetime, etc...) checks out, then
the
recipient can feel confident using the attributes for authorization or other
decisions,
as long as the link back to the authentication cert. establishes that you're
really
talking to the subject to whom the AC was issued.

Is this different from others' view of how ACs are structured and used?

--bob