harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject Re: [classlib][security]Problems about certificate signed by SHA1withDSA?
Date Thu, 11 Jan 2007 09:43:30 GMT
Thank you, Stepan, for all the answers.:)

On 1/11/07, Stepan Mishura <stepan.mishura@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message