From dev-return-22963-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Thu Jan 11 09:44:26 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 86127 invoked from network); 11 Jan 2007 09:44:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Jan 2007 09:44:25 -0000 Received: (qmail 30147 invoked by uid 500); 11 Jan 2007 09:44:26 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 29561 invoked by uid 500); 11 Jan 2007 09:44:25 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 29551 invoked by uid 99); 11 Jan 2007 09:44:25 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jan 2007 01:44:25 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of liyilei1979@gmail.com designates 66.249.82.233 as permitted sender) Received: from [66.249.82.233] (HELO wx-out-0506.google.com) (66.249.82.233) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jan 2007 01:43:51 -0800 Received: by wx-out-0506.google.com with SMTP id i26so430520wxd for ; Thu, 11 Jan 2007 01:43:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=fvs4GCGB7u5snqQ4tIrXvTNr8t5ZQzA/Cf+zbxzzMtk8qOI4Rncr9CK+GkKDUEAvyaucBgYtgXyM+YIg9z7JF4bZn50Ni7QxmxOTRf6S2XTCQXKF+EOtUi+3sbtqVcB4g0t3lK2a7HIJmy4ri8Z4g+qD6cPrkeffDnpKg5y4wjs= Received: by 10.90.115.9 with SMTP id n9mr911298agc.1168508611191; Thu, 11 Jan 2007 01:43:31 -0800 (PST) Received: by 10.90.28.2 with HTTP; Thu, 11 Jan 2007 01:43:30 -0800 (PST) Message-ID: Date: Thu, 11 Jan 2007 17:43:30 +0800 From: "Leo Li" To: dev@harmony.apache.org Subject: Re: [classlib][security]Problems about certificate signed by SHA1withDSA? In-Reply-To: <6e47b64f0701102320i275f44dfg109ba7111a2da7b3@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_25103_17884617.1168508610840" References: <6e47b64f0701102320i275f44dfg109ba7111a2da7b3@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_25103_17884617.1168508610840 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thank you, Stepan, for all the answers.:) On 1/11/07, Stepan Mishura wrote: > > Hi Leo, > > On 1/4/07, Leo Li wrote: > > > Hi, all: > > I am now trying to switch the security provider for Harmony, but I > > have > > a problem: > > > I assume that you replaced BC provider with RI's. Right? Yes, I am trying to test alternatives. If the normal certificate signed by SHA1withDSA is decoded by harmony > > ASN1 decoder, we will get an algorithm as " > > 1.3.14.3.2.26with1.2.840.10040.4.1". Although bouncycastle really has > such > > signature instance, RI security provider does not have such algorithm. > > RI has a signature for "1.3.14.3.2.27" , which is SHA1withDSA. > > > I think we should improve the algorithm. We should first map " > 1.3.14.3.2.26" > to "SHA1" and "1.2.840.10040.4.1" to "DSA" and try to look for > "SHA1withDSA" > signature algorithm. Agree. Improvement is really needed. But what makes things worse is that in > > org.apache.harmony.security.utils.JarUtil, if the security providers has > > no > > "1.3.14.3.2.26with1.2.840.10040.4.1" signature, a "1.3.14.3.2.26" will > be > > sought instead, while some other provider has a SHA1withRSA signature > for > > it, which does not fit the situation.(Luckily enough RI has no such > > signature.) This looks a bit strange. It doesn't make sense for me to search for " 1.3.14.3.2.26" signature algorithm because this OID was assigned to SHA-1 hash algorithm - I think this should be removed. Also OID for SHA1withRSA is "1.3.14.3.2.29" - I have no idea why 'other provider' use SHA1's oid for it. Could you try "1.3.14.3.2.29" for this provider? I will try to make some modification in the JarUtil to see if it works. So my question is: > 1.Whether the "1.3.14.3.2.26with1.2.840.10040.4.1" is the same as " > 1.3.14.3.2.27" signature? > 2.What is the real digit representation of the signature stored in > the > certificate? > > Furthermore, the bcprov.jar itself has a certificate signed by the > SHA1withDSA, but actually the signature is provided by itself. Thus the > signature is absent at the time of loading the jar. Although it does not > matter since the JarVerifier will let it pass as if no certificate existed > when the signature instance is not available, is it more reasonable if we > are able to add the support for such signature in bootstrap security > providers of Harmony, such as DRLCertFactory or CryptoProvider? But we have support for SHA1withDSA signature algorithm. See modules/security/ src/main/java/common/ org/apache/harmony/security/provider/crypto/SHA1withDSA_SignatureImpl.java Great! It seems that the problem I have are just the name mapping of algorithms.:) Thanks, Stepan. Thanks. > -- > Leo Li > China Software Development Lab, IBM > > -- Stepan Mishura Intel Enterprise Solutions Software Division -- Leo Li China Software Development Lab, IBM ------=_Part_25103_17884617.1168508610840--