ietf
[Top] [All Lists]

Re: Gen-ART review of draft-ietf-jose-json-web-signature-33

2014-10-01 10:05:35
I agree, the likelihood of the application correctly walking the path and 
validating the chain is very small.  

I strongly prefer leaving it a MUST use TLS and validate the server per RFC 
6125.

The other thing to note is that the CN of the cert is not in the header.  If 
TLS is not used an attacker could simply modify the DNS to retrieve any valid 
certificate and use that to sign.

Not using TLS breaks the main trust model.  If someone wants to map the "iss" 
to the cert CN and walk the chain to a trusted root, that is fine.  I don't 
think having to have a TLS certificate for the server they are publishing the 
x5u on is going to be an impediment for them.

John B.
On Sep 30, 2014, at 4:08 PM, Dave Cridland <dave(_at_)cridland(_dot_)net> wrote:



On 30 September 2014 19:10, Mike Jones 
<Michael(_dot_)Jones(_at_)microsoft(_dot_)com> wrote:
- In Section 4.1.5, why is TLS required to fetch digitally signed


  X.509 certificates?

 

This question was explicitly discussed by the working group at IETF 87.  The 
discussion is recorded in the minutes as follows:

 

If there is an x5u pointing to a certification issued by a major CA, is TLS 
required for the HTTP query used to retrieve this certificate?  TLS shouldn't 
be needed since the certificate is a signed object.  Therefore, the "MUST" 
use TLS for cert retrieval should be changed to "SHOULD".  This is an 
application decision.  Mike Jones doesn't want removal of TLS in the case 
where there's no external means to verify the retrieved key.  Matt Miller: 
agrees with the jku case, but argues that for x5u, there is a class of 
applications where it isn't known if the retrieved object is self-protecting 
(like a certificate) until after it is retrieved.  Even if the object appears 
to be self-protecting, if the retriever doesn't have a trusted root for that 
object, it might not be able to verify the protection anyhow.  So it use of 
TLS might still be preferable instead of having to potentially retrieve an 
object twice, once over HTTP and then over HTTPS.  Joe Hildebrand wanted to 
know what the upside of this proposal is.  Richard says it saves on TLS 
handshakes; Hildebrand envisions a world where TLS is ubiquitous.  Paul 
Hoffman said that a similar issue in DANE ended up being dropped after a 
couple of months of discussion.  Richard agreed to drop the TLS MUST to 
SHOULD proposal.
 

Russ is certainly right that for certs that chain back to a known root of 
trust, integrity protection isn’t necessary.  It’s also the case that this is 
not true of all certificates that might be used – especially  self-signed 
certificates intended only to carry a key value.  One possibility is to say 
that TLS MUST be used unless the certificate chains back to a known trust 
root accepted by the application.  Of course, just requiring TLS is simpler. 
Do people in the working group want to re-open this issue or are people 
content with the current requirements?




I thought the requirement was confusing as well, however I thought the 
rationale might be entirely different:

JOSE exists, in no small part, because of the difficulty in handling X.509 
within JavaScript. Therefore even where a certificate [chain] is entirely 
valid and properly signed, a JOSE client dereferencing the URI almost 
certainly cannot validate the certificate - yet can validate those used in 
the TLS handshake because of the difference in the API calls possible. 
Indeed, it also cannot validate that the certificate's public key matches the 
private key in the JSON object; making use of a trusted source more important 
still.

So I do support making the x5u require a dereference over TLS, however I also 
think the rationale[s] should be carefully documented in the specification 
otherwise the requirement is likely to be ignored.

(More concretely, I think the specification ought to make TLS a SHOULD here, 
and explain the rationale, and in particular say that it might be relaxed 
only if a consuming application can perform X.509/PKIX path validation).

Dave.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>