Hi Richard, On Tue, 2013-08-20 at 15:43 -0400, Richard Barnes wrote: > It's probably worth noting that this idea that whenever you verify an > object, you have to specify a set of acceptable algorithms, is a > completely new one in the space of crypto APIs. Every API out there > that takes a signed object (cert or SignedData)
Indeed, and I don't think the x.509 cert will parse at all with a missing signature :) > just tells you whether the signature on the object validates, leaving > it to the application to check the algorithm. The BouncyCastle interface that you linked to is deprecated, so I'll discuss the standard java.security.certificate.Certificate class instead. To arrive at a Certificate instance you first typically parse the raw cert bytes with a java.security.cert.CertificateFactory. It will throw a java.security.cert.CertificateException if the signature is missing. We then call the Certificate.verify() method to check the signature, and here we have the choice to use the JVM's default crypto library or an external one like BouncyCastle's. I haven't looked at the source code, but I don't think it's plausible to assume the underlying library would allow an algorithm that is not meant for signing. The verify method specifies a concrete exception - java.security.NoSuchAlgorithmException for that situation. Why doesn't the crypto library do any further checking of the signature algorithm? Because the X.509 spec says any signature algorithm may be used, and the java.security.cert.X509Certificate class complies correctly with that requirement. http://tools.ietf.org/html/rfc5280#section-4.1.1.2 If the application developers choose to allow only specific signature algorithms, the X.509 spec allows them to do so, and they can call the X509Certificate.getSigAlgName() method for that, before or after the signature validation. Vladimir > > CAPI/X.509: > <http://msdn.microsoft.com/en-us/library/windows/desktop/aa377166(v=vs.85).aspx> > BouncyCastle/X.509: > <http://bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/CertificateVerifyer.html> > OpenSSL/CMS: <http://www.openssl.org/docs/crypto/CMS_verify.html> > OpenSSL/X.509: > <http://www.openssl.org/docs/crypto/X509_verify_cert.html> > NSS/CMS: > <http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#98> > > NSS/X.509: > <https://developer.mozilla.org/en-US/docs/NSS_Certificate_Functions#CERT_VerifyCert> > > > In *none* of these APIs is it the job of the verification library to > do algorithm checking. > > > This is yet another way that layering violations in the OpenID use > case are being used to force the crypto layer to deal with things the > application layer should be doing. > > > It's just bad, insecure design. It's not worth it to avoid a minor > parser change. > > > --Richard > > > On Tue, Aug 20, 2013 at 2:50 PM, Anthony Nadalin > <[email protected]> wrote: > I don’t find the text objectionable but I find the > concept/proposal objectionable, as I don’t see the need for > this since there is already a working solution and with the > option that EKR proposed make this a manageable option as this > is how we limit cipher suites today with application that need > to be FIPS compliant. > > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Richard Barnes > Sent: Tuesday, August 20, 2013 11:44 AM > To: Karen ODonoghue > Cc: George Fletcher; Mike Jones; jose issue tracker; > [email protected]; John Bradley; Justin Richer; > [email protected] > > > Subject: Re: [jose] #36: Algorithm "none" should be removed > > > I have already posted proposed text for Option 2 (defining a > new, two-component, one-dot, no-crypto syntax) > > > <http://trac.tools.ietf.org/wg/jose/trac/attachment/ticket/36/ALG-NONE.patch> > > > > > > Would be interested in whether anyone finds that text > objectionable. > > > > > On Tue, Aug 20, 2013 at 2:41 PM, Karen O'Donoghue > <[email protected]> wrote: > > This is perhaps a tiny nit, but I heard you take an > action to write proposed text for discussion by the > working group. I think this is an issue that needs to > be resolved by a concrete set of agreed upon steps and > actual text before interim action is taken to modify > the documents. > > Karen > > > > On 8/20/13 1:33 PM, Mike Jones wrote: > > > Please permit me add a couple more points to > the summary: > > > > - Ekr suggested the possibility of having > libraries, by default, not accept “none” > unless called in a way in which the > application indicates that it is acceptable. > Mike agreed to take an action item to add this > text to the document as a step towards > resolving the issue in a way that addresses > the concerns expressed about the possibility > of downgrade attacks. > > > > - Tony and John pointed out that the issue > being discussed is more general than just > “none” – it’s really the issue of what > algorithms are acceptable to the application. > They said that applications could pass in a > list of acceptable algorithms, which is more > general than special-casing “none”. > > > > - Mike pointed out that people are likely to > use general JOSE libraries processing all > formats (JWS, JWE, unsigned) and so whether > the wire format of an unsigned object looks > like JWS (as it does now) or something else, > libraries would still need to facilitate > applications being written safely, as all > kinds of objects can be processed by these > libraries, independent of the wire format > choice. Thus, the defense against downgrade > attacks needs to happen in the library > interface design, as ekr suggested. > > > > > -- Mike > > > > From: Richard Barnes [mailto:[email protected]] > Sent: Tuesday, August 20, 2013 7:33 AM > To: George Fletcher > Cc: Justin Richer; John Bradley; Mike Jones; > jose issue tracker; [email protected]; > [email protected] > Subject: Re: [jose] #36: Algorithm "none" > should be removed > > > > If I may summarize the call: > > > > > -- There was agreement that we should define a > "header + data" format, with no cryptographic > protection > > > > > > -- There was disagreement on whether that > unprotected format should be part of JWS, or > something separate. Two options were > proposed: > > > 1. Use JWS, but require that implementations > MUST NOT accept "none" unless explicitly > directed to by an application > > > 2. Define a new format, distinct from JWS, > that just has header and payload (no > signature). In the compact format, this would > just have two dot-separated components. > > > > > > -- It was observed that either one of these > options causes work for existing > implementations. Option 1 causes them to > expose API surface that may not be there now > (to specify acceptable algorithms). Option 2 > requires a change to parsing. > > > > > > > > > > > On Tue, Aug 20, 2013 at 10:09 AM, George > Fletcher <[email protected]> wrote: > > > > On 8/20/13 9:49 AM, Justin Richer wrote: > > > > > On 08/19/2013 05:46 PM, Richard Barnes > wrote: > > > > > [snip] > > > > > It's important that something > that is not signed is does not > pass JWS validation. If > something unsigned is ever > accepted as a valid JWS, then > there's a huge downgrade risk. > > > > > > > I think that's a red herring. It's the > same downgrade risk if someone sends > alg:rot13 and your app doesn't want to > accept that "signature" either. A JWS > with alg:none should pass *only* if > the signature field is empty, full > stop. > > -- Justin > > > > > +1 > > And to take it even a bit further. There will > come a time in the future when HS256 is deemed > to be insecure and SHOULD NOT be used because > it's been hacked/compromised. At that point in > time, all the implementations will have to > have a way to not allow alg:256. Hence there > could be no security difference between > alg:hs256 and alg:none at some point in the > future. > > I realize I missed the call last night so > maybe this is all mute:) > > Thanks, > George > > > > > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
