Jim Schaad August Cellars JOSE Feature Set Jim Schaad August Cellars

Capability List from CMS (1) One Pass Processing (I,E) Interior Content Identification (I,E) Content encoding methods (I,E) Parallel Signatures (I) Protected Attributes (I,E) Unprotected Attributes (I,E) How much effort are we looking at for processing during the serialization process? Is interior content identification a suggestion or somehow a unique requirement? What methods of encoding of content are going to be allowed? Encapsulated, Detached, Embedded – one response saying not embedded The ALTO group is currently defining a detached method where the content is in the body and the HTTP header has the sign header and value info Are parallel signatures allowed in an integrity object. There exist ways to do this. If this is supported is it going to depend if we are looking at a signature or a MAC algorithm being applied to the object? Are we supporting the ability to have signed or authenticated attributes for both the integrity protected and the encrypted formats – AEAD algorithms such as GCM are called for but not fully utilized.

Capability List from CMS (2) Multiple Recipients (I, E) Recipient Encryption Methods (I, E) Key Transport (RSA) Key Agreement (ECDH) Static-static, ephemeral-static, ephemeral-ephemeral Pre-Shared Secret w/o Key Derivation Pre-Shared Secret w/ Key Derivation (Password) Other (IBE, Plasma) Using HMAC or Encryption can we setup for multiple recipients to have different keys and get the message?

Capability List from CMS (3) Recipient/Signer Identification (I, E) Re-serialization (I) Currently support URL and hash, what about the traditional issuer/signer option? Do we want to allow for re-serialization of content –implies some degree of canonization, but may be required if we want to allow for detached contents. This is a very hard problem as was found in XML, only slightly less of a problem for S/MIME

Discussion?