The JavaScript Message Security Format (JSMS) is quite a nice piece of work.
1. Signer as URI Uhm... 2. URI in cert Requiring a certificate to include a subjectAltName.uniformResourceIdentifier (san.uri) seems to exclude a lots of potential certs, without a great reason. Do XMPP ids typically get put in certs as URIs (san.uri=xmpp:[email protected]), or as a dedicated name-form ([email protected])? An email address can be expressed as a URI (eg mailto:[email protected]), but a corresponding certificate is likely to include a san.rfc822 value, not a san.uri. 3. Signer = cert.san.uri Why does the cert have to match the Signer field? In TLS-with-client-auth or S/MIME you have the cert, but no separate Signer id (though I guess S/MIME has a separate email address). 4. Examples The example certificate [4.4.2.1] doesn't verify the example signature [4.4]. It would be a nice test vector if it did verify. 5. Base64 I would prefer to use base64url without terminators, instead of original base64. The "outer" layer of JSMS is a JSON dictionary, but I expect it will often be encoded for transmission and that encoding should be consistent with the encoding of content within JSMS. Avoiding + / and = characters removes an unnecessary layer of escaping when values are used in URIs, form POSTs, HTTP headers etc. 6. MAC Supporting a symmetric MAC would cover another useful set of use cases. 7. WOES It would be helpful to explicitly mention in future drafts where discussion should occur, ie on the WOES list. Typos: Section 4.4.1. "Signature Computation", point 2. WRONG "feed the literal octets of the signature into the digest" RIGHT "feed the literal octets of X into the digest" -- James Manger
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
