Your description below confuses the JWS Payload (which can be any octet 
sequence) and the Encoded JWS Payload (which is the base64url encoded 
representation of the JWS Payload).  For instance, you made a typo in your 
point 3.c.iii below by writing "JWS Payload" when you meant "Encoded JWS 
Payload".

Likewise, your first point 3 in your proposed 8.1 should be referring to the 
Encoded JWS Payload - not the JWS Payload.  Similarly, you left off the 
"Encoded" in the second point 3 of your proposed 8.1.

Likewise, you are confusing the Encoded Payload and the Payload in your 
proposed 8.2 text.  The payload has to be able to represent any octet stream, 
which your text doesn't enable.  That's why we have the Encoded Payload in the 
first place.

Do you want to revise your proposal to eliminate this confusion, 
differentiating between the JWS Payload - which can represent any octet 
sequence, and the JWS Encoded Payload, which is a URL-safe, JSON-string-safe 
representation of that octet stream?

I understand that editorially you're trying to restructure the signing and 
verification sections to be more agnostic to whether there are multiple 
signatures.  I don't have any issue with that.

                                                            Thanks,
                                                            -- Mike

From: [email protected] [mailto:[email protected]] On Behalf Of Jim 
Schaad
Sent: Friday, June 28, 2013 9:07 PM
To: [email protected]; Mike Jones
Subject: [jose] Propsoed Signing Procedure

I would suggest something along the following lines.  It is still missing some 
of the descriptive text that is required, but not a great deal of it.

Jim



5.1 Message signing or MACing

To create a JWS, on performs the following steps.  The order of the steps is 
information, however the result of performing the steps is prescriptive.


1.       Verify the content to be used as the JWS Payload is an octet stream.  
If it is not then the fail.

2.       If a common signature header field exists, then serialize the object 
describing the header using UTF-8 and then base64 URL that result.  This is now 
the Encoded JWS Header.

3.      For each signature to be created perform the following steps:

a.      Obtain the algorithm to be used for the signature operation.  This may 
be in the common signature protected header, the common signature unprotected 
header or the signature header objects.  If this is not a legal and supported 
signature algorithm then fail.

b.      Verify that the key to be used for the signature operation is 
compatible with the signature algorithm.

c.      Concatenate the following values for the octet stream to be signed:

                                                    i.     The Encoded JWS 
header if it exists,

                                                   ii.     One period character 
('.')

                                                  iii.     The JWS payload

d.      Compute the signature value using the key, the signature algorithm and 
the octet stream to be signed.

e.      Base64url encode the signature value, this is the Encoded JWS signature.

Section 8.1  Compact serialization

In order for a compact serialization to be created, the following conditions 
must be met:

1.      There must be exactly one signer

2.      There must not be a common unprotected header field or a signer header 
field.  These can be combined before the signature is created to form the 
common protected header field.

3.      The JWS payload MUST conform to the character set which is used for 
base64url encoding.  This is A-Za-z0-9 (and whatever the rest of them are)

The compact serialization is formed by concatenating the following items:

1.      The Encoded JWS Header,

2.      One period character ('.')

3.      The JWS Payload

4.      One period character ('.')

5.      The Encoded JWS signature

Section 8.2  JSON Serialization

The JSON serialization is an object with the following members:
Protected            - a string containing the Encoded JWS Header (OPTIONAL)
Unprotected      - an object containing any common unprotected header values 
(OPTINAL)
Payload                - a string containing the JWS Payload (REQUIRED)
Signatures           - an array containing one element for each signature 
created.  Each array element consists of an object with the following members:
                Header - an object containing any signer specific unprotected 
header values (OPTINAL)
                Signature - a string containing the Encoded JWS Signature for 
that signer.






_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to