Introduction to the concept: extension to S/MIME, using policy controls.

*Problems:
ESS:
- Access to information and access to security label are the same,
  i.e. a receiving client can choose to access information even
  if the receiving user is not granted access.
- Access policy must be distributed in advance.
- Only one label per message is allowed, which doesn't work well
  across multiple organizations
S/MIME:
- Only a single credential type is allowed (PKIX certificates)
- In order to communicate with a user using S/MIME encrypted
  email, the user's encryption certificate needs to be discovered
  first.
- No MTA content scanning (malware) is possible, because MTA
  has no access to the private key

*Requirements:
- Allow for multiple policies; different authorities; multiple scopes
- Allow for access control to be amended before messages are decrypted/retrieved.
- Varying levels of identity assurance
- Independent of authentication technology, e.g. allow users to authenticate
  using a username/password to participate, even if they don't have a PKIX
  certificate that they can use with S/MIME.
- Varying service types for recipients (including cloud).
- MTA can access protected messages.

A proposal is to define a new web based protocol for generating
S/MIME keys and policy blobs for use with S/MIME.

The proposal on the table extends S/MIME, doesn't reinvent it.
There is a desire to preserve what is working/implemented.

Some detailed discussion on use cases followed. Why not just use a web server
which can store files (and forward URLs), instead of using S/MIME?

Some participants observed that this shouldn't be limited to email messages,
for example XMPP and Access Controls for Web pages can also take advantage
of this.

Concern about lawful intercept (the "MTA can access protected messages"
requirement).

Concern about existing IPR. Only known patent in this area expires in
18 months.

Reasonable interest in the work in the IETF.