Re: [jose] I-D Action: draft-ietf-jose-json-web-signature-02.txt

Thanks again.  Responses inline...

-----Original Message-----
From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org]<mailto:[mailto:jose-bounces@ietf.org]> On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
To: jose@ietf.org<mailto:jose@ietf.org>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-signature-02.txt

Here are some comments on the draft (a lot of these are duplicates from

web-encryption):

1) s2 & Requirements Language: The RFC editor is going to move the Requirements Language section later on so you might as well save them the trouble and just make it part of s2.

Done

2) s3: This is probably a style thing, but I think it's probably better to talk about the structure first and then provide an example.  It's just going to make everybody ask you to define/explain x in that section.

See JWE response

3) s4: Contains the following:

  The Header Parameter Names within this object

  MUST be unique; JWEs with duplicate Header Parameter Names MUST be

  rejected.

I'd prefer to see that if this is actually enforceable (not sure it is) that an error gets thrown or the message gets rejected.

See JWE response

Also just checking that this means you can only send one signature type per object.  That is you can't send one JSON object that is signed with both RSA and ECDSA?

See draft-jones-json-web-signature-json-serialization for multi-signature capability

4) s4: How are the different types of parameters (res,pub,priv) named?

Is there going to be some kind of designator in front of them?  If so, then I would definitely try to get an early review from some Apps folks because they're deprecating X-.

See JWE response

5) s4.1/4.1.1: Same concerns about the registry setup as the other docs.

See JWE response

6) s4.1.2/s4.1.4: Add normative reference to [RFC3986] for absolute URL.

  And I think they call it a URI.

Done

7) s4.1.4: Add reference to RFC5280: X.509 public key certificate or certificate chain [RFC5280]

Done

8) s4.1.4: Ack! PEM.  Replace the reference to PEM with RFC 4648 and pointer to s4.

See JWE response

9) s4.1.6: let's just do DER: r/DER/BER/DER [X.690]

Done

and add the following normative reference

   [X.690]  ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,

            Information technology - ASN.1 encoding rules:

            Specification of Basic Encoding Rules (BER), Canonical

            Encoding Rules (CER) and Distinguished Encoding Rules

            (DER).

Done

or: r/DER/BER PKIX certificate value/PKIX certificate value [RFC5280].

10) s7: If the kid and thumbprints are not supposed to be generated in a way to make them unique it's worth pointing this out in s7.  I might suggest something along the lines of:

   While hash algorithms provide collision resistance, this property

   is not needed for key identifiers or thumbprints.

I'm just as confused here as for your equivalent comment in JWE.  Section 7 is the IANA Considerations.  Try again???

11) s11.1: encoding considerations: isn't it base64url encoded?

Same text used as JWE

            applications that use this media type: is it just OpenId connect or can this be generalized a bit?

Now reads:  OpenID Connect, Mozilla Browser ID, Salesforce, Google, numerous others that use signed JWTs

spt

_______________________________________________

jose mailing list

jose@ietf.org<mailto:jose@ietf.org>

https://www.ietf.org/mailman/listinfo/jose