Subject: [jose] Signature Capabilities

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Oct 2011 13:34:44 -0700

I was hoping to see mail on this issue before this point.  This is still a
personal issue and not a chair issue.  I would like to see what the
capability set from the other standards are deemed as important for the JOSE
work.  

This message is the first in a series of four messages on the different base
structures that are presented in the CMS specification.

This message will hopefully start a discussion on signature capabilities.  I
recognized that the JOSE work is planning to focus on doing both signature
and authentication as a single object focusing on integrity.  However for
the purposes of this discussion I would like to separate those two and then
combine them later so that we don't get confused on the set of issues needed
for each of the, in my eyes, significantly different operations.  (This is
not to say that I believe they HAVE to be separated in the final document
that will depend on the capabilities that we end up with.)

1.  One Pass Processing - Should one be able to perform hashing
functionality as part of the serialization process?  If this is something
that should be able to be doable, should this be doable for the sender, the
recipient or both?

2. Identification of interior content - Should one be able to identify the
interior content?  If so should this be a unique value or just something
that is to be a hint?

3.  Inner content encoding - Should one be able to sign just JSON objects,
or are other types of objects to be signed as well?

4.  Different ways to encode the content - Should the content be any of the
following:
	Encapsulated - The signature structure encapsulates the content
	Detached - The content can be sent independent of the signature
structure
	Embedded - The signature structure can be embedded in the content
structure (this is allowed by the XML DigSig work)

5.  Multiple Signatures - Are multiple, parallel signatures allowed?  Are
nested signatures allowed?  Are counter-signatures allowed (i.e. signatures
on signatures w/o the content).

6.   Signing Key Identification - What methods of identifying the signing
key are to be considered?   Are keys to be only contained in PKIX
certificates or are other ways of describing keys to be allowed? 

7.  Signed Attributes - Is there a need to sign anything other than just the
content?  This would include any of a number of different items such as a
timestamp, the signature algorithm and so forth.  A pure implementation
issue that is part of this question is the question of signing the content
indirectly vs directly. 

8.  Unsigned Attributes - should a standard method of attaching unsigned
attributes to a signature be defined?  Currently the only one used by CMS is
the countersignature attribute.

9.  Re-serialization - How hard should one need to work to re-serialize a
parsed JSON security object to get back the same object.  I believe that
this is currently considered to be beyond the scope of the work.  Is this
correct?

Jim

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 5 Oct 2011 07:03:10 +0800

On 2011-10-05 at 07:34:44, Jim Schaad wrote:
> functionality as part of the serialization process?  If this is 
> something that should be able to be doable, should this be doable for 
> the sender, the recipient or both?

The existing proposals seem to permit it.

> 2. Identification of interior content - Should one be able to identify 
> the interior content?  If so should this be a unique value or just 
> something that is to be a hint?

A URI perhaps.

> 3.  Inner content encoding - Should one be able to sign just JSON 
> objects, or are other types of objects to be signed as well?

There has been discussion on this point at a couple of meetings.  The conclusion was that the signed object was a sequence of octets.

Content-type is handy; especially if you are thinking about nesting signatures or other arrangement where the content is of non-deterministic type.  The JSON proposal includes a parameter for this purpose.
 
> structure (this is allowed by the XML DigSig work)

I think that one of the stated goals is simplicity.  You don't get that with Embedded.

It would appear that current proposals all head toward Encapsulated.  It seems that this is a sensible decision.  Nothing would prevent someone from proposing Detached, though I expect there to be push back on that.

> 5.  Multiple Signatures - Are multiple, parallel signatures allowed?
> Are nested signatures allowed?  Are counter-signatures allowed (i.e.
> signatures on signatures w/o the content).

Parallel signatures seems to be a bit of an unnecessary optimization.
Nesting seems to be no trouble; counter-signing a little more tricky.
 
> certificates or are other ways of describing keys to be allowed?

There has been discussion on providing an encoding of bare keys: c.f. draft-jones-json-web-key

> 7.  Signed Attributes - Is there a need to sign anything other than 
> just the content?  This would include any of a number of different 
> items such as a timestamp, the signature algorithm and so forth.  A 
> pure implementation issue that is part of this question is the 
> question of signing the content indirectly vs directly.

In the interest of expediency, these can be signed if they are encapsulated in the signed octets.
 
> 8.  Unsigned Attributes - should a standard method of attaching 
> unsigned attributes to a signature be defined?  Currently the only one 
> used by CMS is the countersignature attribute.

Doesn't seem particularly important.

> 9.  Re-serialization - How hard should one need to work to 
> re-serialize a parsed JSON security object to get back the same 
> object.  I believe that this is currently considered to be beyond the scope of the work.
> Is this correct?

The inner content is simply octets.  So, if it happens to be JSON, then re-serialization is unlikely to be possible.