Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])

From: [email-masked]
Date: Wed, 4 Nov 1998 22:16:33 -0800

an issue was binding of real-time attributes ... needing real-time access
to the account record .... or in a CA model the real-time invalidation &
real-time re-issue of a certificate anytime any of the real-time attributes
changed (i.e. like everytime you bank account balance changed ... which
possibly opens up the privacy issue of all this attribute information
flying around the world).

if the attributes have to be accessed to complete the transaction ... then
the account record can be used in lieu of certificate to create a binding
between a public key and the attributes in question. If the transaction has
to touch the account record where the binding between the real-time
attributes and public key is located .... then a certificate with (possibly
stale) duplicate binding is superfulous to include in such a transaction.

fundamentailly there are business requirements for authentication bindings
.... (passwords, shared secrets, public key, etc). this has been implemeted
and deployed for a very long time in the account-based world. one could
characterize certificates as having been created to extend a similar
capability into an offline environment. trying to propogate the offline
(relatively static/stale) certificate solution back into an online
environment where there exists a much richer capability for real-time
attribute authentication bindings would be at least superfulous .... and at
worst creating unecessary risks & liability.

---

From: Jun Yoshitake <[email-masked]>
Date: Thu, 05 Nov 1998 21:23:48 +0900

Lynn,

I may misunderstand you, but
I am wondering why a real-time attribute
(which causes the privacy issues, etc.)
has to be included in a certificate.

I think the following method would be better:

  A certificate shows the static binding
  between the subject and the public key.

  A real-time attribute is accessed inside the
  application server after the successful
  validation of the certificate. ("OK, this
  transaction has surely come from this
  entity, then we access the real-time
  attribute of the entity.")

Jun Yoshitake

Mitsubishi Electric Corp.

---

From: Francois Rousseau <[email-masked]>
Date: Thu, 05 Nov 1998 13:47:45 -0500

Jun and Lynn,

As indicated by Jun, a public-key certificate is meant to cryptographically
bound a public key to a user for authentication and identification
purposes, and should last as long as the strength of the cryptographic
algorithm used to sign this public-key certificate will permit unless it
needs to be revoked for various reasons.

For these volatile attributes, this is why Attribute Certificates have been
defined under X.509 (1997) and ANSI X9.57 (1997). An Attribute Certificate
is meant to cryptographically bound attributes (i.e. privileges) to the
public-key certificate of this user for access control and authorization
purposes, and should last as long as required by these privileges, which
can be extremely short or longer as required.

Francois Rousseau
AEPOS Technologies