Tero - for your point "2) Hash inside "alg" and inside the signature", could you please write proposed security considerations text addressing this issue? I'd think it should describe the need for implementations to ensure that signature verification is done for the exact algorithm specified in the "alg" header parameter, no matter what algorithm information may (or may not) have been encoded into the signature value in an algorithm-specific manner. For your point "3) There is no explicit warning about the "alg" "none"", I plan to add the additional step that you suggested. For your point "4) Thumbprint formats" if you or someone else wants to define an additional thumbprint format for use in IoT contexts (or any other contexts), I encourage you to write an Internet Draft that does so, registering the new header parameter defined in the JSON Web Signature and Encryption Header Parameters registry. Thanks, -- Mike -----Original Message----- From: Tero Kivinen [mailto:kivinen@xxxxxx] Sent: Tuesday, September 16, 2014 2:27 AM To: Mike Jones Cc: iesg@xxxxxxxx; secdir@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-jose-json-web-signature.all@xxxxxxxxxxxxxx; jose@xxxxxxxx Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 Mike Jones writes: >> This document is part of the jose-json document set, and describres >> the JSON Web Signatures. >> >> The security considerations section includes text which says: >> >> The entire list of security considerations is beyond the scope of >> this document, but some significant considerations are listed here. >> >> but also lists quite a lot of security considerations. I think the >> security considerations covering this document should be in scope >> with the document. Of course there are generic security >> considerations which might be outside the scope of this document, but >> I do not think we need to explictly mention those. > > Several reviewers have objected to this sentence. Its removal is > planned. Good. >> 2) Hash inside "alg" and inside the signature >> >> Also in some cases the signature itself has the hash function stored >> internally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid >> inside the signature, so what should the implementation do if the >> "alg" parameter outside the signature does not match the oid inside >> the signature? I.e the signature using "alg" of "RS256", but inside >> the signature the oid is using the "SHA1". Most crypto libraries will >> just take the oid from the signature, and use that to verify the >> message. Adding some description what to do in such situation would >> be needed. >> > I think there's some confusion here, since the JWS spec does not use > any OIDs or ASN.1 for signatures. Rather, the cryptographic operations > to be performed are fully specified by the "alg" value and the > signatures are represented as base64url encoded octet sequences > representing the signature values produced by the signature > algorithms. But JWS uses RSASSA-PKCS1-V1_5, which DOES have ASN.1 inside. I.e. if you look at the RFC3447 section 8.2 (referenced from the draft-ietf-jose-json-web-algorithms-31) you will see that when you generate signature, you first to EMSA-PKCS1-V1_5-ENCODE operation (section 9.2 of RFC3447) to the message. This will take the hash of the message, then create the DigestInfo ASN.1 object, which includes the oid of hash algoritm used in previous step and the actual output of the hash, and finally you encode the EM by padding that DigestInfo with suitable padding. After that you do the RSA operation. When verifying the signature, you do RSA operation, verify the padding and extract the hash oid and hash value out from the ASN.1 and then generate EM' by doing EMSA-PKCS1-V1_5-ENCODE operation to the original message using hash algorithm specified by the oid extracted by previous operation. In most cases the libraries will always do that automatically, and there is no way to specify that you want to use some other algorith, than what is stored in the ASN.1, as if you use any other algorithm that was exactly same than what was stored in the ASN.1 inside the RSA signature the verification will fail. In your case there is now two algorithms, the outer "alg" algorithm and the one inside the signature itself. So even if the outer "alg" says "RS256", the hash used in the signature might be MD5, and most crypto libraries will simply verify the signature fine, and this can cause security problems. >> 3) There is no explict warning about the "alg" "none". >> >> In the section 5.2 it says that "at least one signature ... MUST >> successfully validate", but that does not limit alg "none" out from >> it. I.e. if the application policy is to "one signature needs to >> validate", and it gets JWS that has "none" as one of the algorithms, >> then it will accept it. >> >> I think there should be warning here or in the security >> considerations section about the "none" algorithm, especially as the >> algorithm itself is defined in the different draft (perhaps just >> reference to the section 8.5 of the [JWA] draft). > > This warning is present in the spec where the algorithm is defined > specifically - > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31 > #section-8.5. (Note that the working group decided to define > algorithms in a separate spec than the ones in which they are used.) > > Also note that it is up to applications which algorithms are > acceptable in a given context - not just "none" but also other > algorithms that might be deprecated or inappropriate for some other > reason. Unless the signature algorithm used is acceptable to the > application, it should not accept the JWT. The current draft does not have any steps for such policy checks. So it would be good to add new step in section 5.2 which says that verify that the algorithms used in the signature are allowed by the policy in the current context. Also noting that "none" is not really usable signature algoritm ever... >> 4) Thumbprint formats >> >> Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but >> those are over the whole certificate. >> >> With the thumbprints, it has been noted lately, that quite often it >> is more useful to use the hash of the SubjectPublicKeyInfo object of >> the >> >> X.509 certificate, than the full X.509 certificate. This method has >> been used in the raw public key methods (draft-ietf-tls-oob-pubkey, >> draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has two >> options one for the full certificate and another for the >> SubjectPublicKeyInfo object of the certificate). >> >> Using hash of the SubjectPublicKeyInfo object allows changing the >> certificate without invalidiating the certificates, i.e. when >> changing CAs, or switching from SHA1 to SHA2 in certificates, or just >> renewing the certificate. It also allows using raw public keys which >> do not have defined X.509 certificate format, but which can be >> converted to the SubjectPublicKeyInfo object when calculating the >> thumbprints. This is very important in the Internet of Things type of >> things, which might not be using the full X.509 certificates. > > This thumbprint definition matches existing practice in commonly used > software packages. For instance, both openssl and Windows use > certificate thumbprints of this kind. Yes, I am not saying we should remove them. > That being said, there's nothing preventing another specification from > defining a different thumbprint calculation over the SPKI information > and a header parameter used to represent it. The header parameters are > extensible via a registry. Yes, but as I think those formats using SPKI are much more usable, especially in the internet of things contextes, it might be good idea to define them now, not year later. On the other hand if these formats are not meant to be used in the Internet of Things contextes, then never mind... >> 5) Terminology ordering. >> >> Terminology is not in any order. It would be useful to have it either >> in logical order (i.e. define terms before they are used), or in >> alphabetical order. >> >> Now for example the "JWS Protected Header" is used before it is >> defined in the "JWS Signature", and "Header Paramater" is between >> "JWS Signature" and "JWS Protected Header", also "JWS Signature" >> uses both "JWS Payload" and "JWS Protected Header", and one of those >> is defined before and one after the "JWS Signature". > > The terms are listed in top-down order, with related terms grouped > together. Thus "JSON Web Signature" is first, the members that make up > a JWS object are listed together in the order that they appear in a > JWS, etc. That being said, I'll plan to review the orderings and make > sure that they consistently follow those ordering rules. Ok, thanks. -- kivinen@xxxxxx