[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: [dev-crypto] Re-usable PKCS#10 CSR generation.
From:       Martin Paljak <martin () paljak ! pri ! ee>
Date:       2010-05-24 11:24:04
Message-ID: 61F3DAB3-7C03-45E5-BC1B-BB592DC71205 () paljak ! pri ! ee
[Download RAW message or body]

Hello,

On May 21, 2010, at 09:00 , David Hook wrote:
> The mods are probably a bit too low level for what we have to meet.
What do you mean with this? That the modification deals with a too low level of \
bit-tricking, which is not suitable for BC or that the patch does not meet the \
required consistency level to be considered?



> There's been a bit of a discuss about this here as well. If you look at
> some of the things we're currently doing in the CMS API it's pretty
> clear we've stretched the provider architecture as far as it will go.

I'm sorry, I probably lack the context as I've only used BC, never looked under the \
hood before.


> At the moment we're considering creating some interfaces which provide
> the basic operations (such as sign, verify) in a way not dissimilar to
> how the interfaces are defined in the light weight API. This would allow
> us to break things like CMS, PKCS#10 and certificate generation away
> from the actual JCA/JCE. There's a bit of work in this though, and I'd
> certainly be interested in any feedback on the idea that people might
> have.

I have a real life need which I fixed with the mentioned patch. As said, it is easier \
and more logical (IMHO) to provide means for such structure manipulation instead of \
creating a "mini intermediate provider" for the specific case (which, indeed, might \
fit better into the current BC design)

If there's anything I could provide or help with, please let me know, but I currently \
did not understand if the approach is not OK or the specific patch is not OK (for \
lacking docs or some specific checks or something similar)


Thanks,

Martin

> 
> Regards,
> 
> David
> 
> On Thu, 2010-05-20 at 16:17 +0300, Martin Paljak wrote:
> > On May 20, 2010, at 16:12 , Tomas Gustavsson wrote:
> > > 
> > > The way I do this is simply by using a java provider that does the off-loading.
> > > 
> > > req = new PKCS10CertificationRequest(signAlg, x509dn, keyPair.getPublic(), \
> > > attrset, keyPair.getPrivate(), pkcs11Provider); 
> > > I guess your usage is if you don't have a provider and then you can fix the \
> > > signature bits in any way you want?
> > Correct, the private key resides in the smart card and there is no software \
> > interface for this operation yet, as the code is used during card \
> > personalization. Even if it was possible to create a little wrapper provider for \
> > this specific purpose, I would not know from where to start and I don't find it \
> > feasible and the approach with getBitsToSign/setSignedBits works perfectly in \
> > this situation. Also, I think that a "generic" PKCS#10 manipulation interface is \
> > more useful than something that is tied to JCE/JCA. 
> > 
> > 
> > 
> > 
> > > 
> > > /Tomas
> > > 
> > > On 05/20/2010 12:50 PM, Martin Paljak wrote:
> > 
> > 
> > 
> 
> 
> 



-- 
Martin Paljak
http://martin.paljak.pri.ee
+3725156495


[prev in list] [next in list] [prev in thread] [next in thread]