Subject: [woes] Comments on draft-rescorla-jsms-00

From: "Manger, James H" <[email-masked]>
Date: Tue, 29 Mar 2011 17:25:45 +1100

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-masked]), or as a dedicated name-form (san.other.xmpp=[email-masked])?

An email address can be expressed as a URI (eg mailto:[email-masked]), 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Mar 2011 09:58:56 +0200

On 3/29/11 8:25 AM, Manger, James H wrote:

> 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-masked]), or as a dedicated name-form
> (san.other.xmpp=[email-masked])?

There is an OID called "id-on-XmppAddr", but you're right that it could
be a URI.

> An email address can be expressed as a URI (eg
> mailto:[email-masked]), but a corresponding certificate is likely to
> include a san.rfc822 value, not a san.uri.

Correct. It would be nice to standardize on one subjectAlternativeName
extension, but I don't think that's very likely given wide deployment of
things like rfc822name.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/