RE: Position Paper for W3C Workshop on Identity

It's a great couple of questions. It focuses on what bits might we borrow
from standard that didn't quite make it (that everyone else overlooked).

Why did Attribute Cert not work on the web (whereas id certs did)?

And, how did ISO distinguish the properties of issuing one signed blob (AA
cert) vs another signed blob (id certs), semantically? Were they supposed to
complement? If so, how?

Adoption never really failed. It never really got started. That's because of
timing; since the ISO text for AA happened only well after the main web
adoption of id certs (and folks had used alternative methods meantime, for
authZ). Furthermore, id certs can do 80% of what signed AA certs provide.
NSA proved in early 1990s with the v1 cert that one can tag (2) public keys
withinthe subjectPublicKey blob ... and attach authZ attribute to them
indicating security labels and caveats and other military management
privilege bits, for B3 operating systems.

I'm not sure, it's been so longer since I was half-involved, whether
military S/MIME actually uses AA certs or not. David will know.

The main difference, and this is where we need to note something, was in how
one expected AA certs to be issued and managed.  Their lifecycle and control
properties are different to id certs. This is something we might learn: that
whereas id certs are about controlling the delivery of semantics-specific
telematics security services (and the crypto mechanisms that properly
supports the various enforcement semantics), AA certs are not. AA certs are
mostly about the application of secure channels (not the assurance/delivery
of the secure channels).  There is some interplay between these layers in
military circles, when one needs an authz to support formation of the secure
channel. For example, you cannot release a secret memo to someone;s who cert
WOULD preclude them from reading it, since their key is not tagged secret.
Similarly, if one does get a secret memo, one cannot even process the
CIPHERtext of the block tagged secret - as the crypto primitive will never
even be armed.

For example, under a multi-level access control or integrity security
doctrine, the situation faced last year in IETF of one part of an HTTP
request coming from one payload delivered under one security handshake being
then mixed with another half HTTP request coming from a payload controlled
by another handshake... never occurs. One can NEVER mix payloads from two
different security contexts, under MLS. They are two half HTTP requests,
which equals no request - as neither half type checks (and data in separate
queues cannot be combined).

Sharon designed quite an extensive control/issuing system tuned to the
ISO-ideas on the authz problem (using signed blobs/PACs). It was not merely
military AuthZ - but attempted to conceive of something open infrastructures
might use. It looked at the lifecycle, and who works together to make an
open system for authZ.

Arguably, pushing a signed XML blob in websso (or a mac-signed openid), or
pulling an OAUTH record.... plays the "role" anticipated for the AA cert
(and indeed the role played by pulling an foaf card). None of them have the
lifecycle properties of AA, but they have the functional aspects done.
Furthermore, websso protocols are tuned up for the web (redirects,
auto-posts, etc); whereas signed AA blobs were not web-specific. They really
focused on being added to the SSL handshake as an additional cert  type,
which never happened. Lots of DoD politics around the Defense Messaging
System "influenced" the US defense vendors fronting DoD in IETF/IESG PKI/SSL
WGs, who duly ensured AA went nowhere. At the time,  DoD was ordained to be
in charge of civilian infrastructure - and they had the WGs tied up to do
their bidding. If THEY didn't want it for US, the internet standards duly
reflected that.

Received on Saturday, 23 April 2011 23:47:54 UTC