proposal to add attribute certificates to TLS 3.1


They are a signed object that asserts additional properties with
respect to some identity certificate. An attribute cert has no
associated key pair and consequently cannot be used to establish
identity. Informally, one can think of them as a mechanism for
extending the attributes of an identity certificate (noting that the
extended attributes may be signed by a different CA than the base

Attribute certs typically have a much shorter lifetime than identity


Some of our customers have identified a particular problem that could
easily be solved by introducing AttributeCerts: some individuals take
on temporary roles within the organization and there is need to grant
temporary authorization to access additional sets of data. This can and
does happen, for instance, when some manager goes on vacation.  In the
paper world, the temporary manager is given "signing authority" for
things normally covered by the vacationng manager.

An AttributeCert would be used in a corresponding way: permission to
take some action would be encapsulated into an attribute certificate
with a lifetime that covered the period of the vacation.

                Side Effects 

If the the AttributeCert hammer gets created, a number of potential
problems start turning into nails.

a) Since individuals change roles more often than indentities, we risk
exploding the size of CRLs as new certificates have to crafted as those
roles change.

b) This allows the cost of carrying around athorization to be amortized
across the users who are making use of it. The need for distributing
access control lists to all servers in an organization would go away.
A central authority could issue short lifetime AttributeCerts on a
regular basis and publish those in a public place or directly to the
owners of the base certificates.

c) This more clearly allows the separation the uses of authentication
(identity) and authorization (permission). Many bugs get introduced
into security models when those two "auths" are confused.

d) By retaining the base identity cert, maintaining access logs becomes
simpler to the application above TLS.

e) If all the data needed by any server relevant to a single individual
had to be in that individual's identity certificate, that certificate
might become unwieldy because of size. This allows attributes to be
bundled in logical groups.


I will wave my hands pretty fast here, but not so fast that I leave the
ground. :-) Details should be able to be tied down in a straightforward
manner if the TLS working group decides to proceed. (This means that I
am not much interested in discussing the details of the following. It
is only being presented as a suggestion (not a proof) of concept.)

An AttributeCert could have much the same syntax as a X.509v3
certificate with a null public key.

There would be a required attribute that would identify the base
certificate to which the rest of the attributes apply. The value of
that attribute might contain the public key of the base certificate, or
a secure hash of the entire base certificate or both.

The TLS protocol would be augmented by allowing the server to include
an AttributeCertifcateRequest message following a CertifacteRequest
message and before a ServerKeyExchange message (if any). The message
would consist of a list of tuples
        list of attributes required signing authority (as in a
        CertificateRequest message)

The client would then optionally send a second Certificate message
containing the AttributeCert following the base certificate chain and
before the ClientKeyExchange message.

Philip L. Karlton
Principal Curmudgeon
Netscape Communications

	This kind of rotor is known as a squirrel-cage rotor
	because the way it's wound is like a bird cage.

Received on Friday, 26 July 1996 21:32:49 UTC