[xmlsec] nss updates

[Andrew Fan]

Hi Tej,

I have no significant reason for that, I raise the question just because 
usually I use the "*Wrap" function, and in some cases, the (a)symmtric 
key can not extract from hard devices unless in a wrapped format. But in 
the context of xml signature and encryption specification, this is not 
true anymore, every key to be wraped or transport must appear in plain 
text. I just wonder does your method get the correct result. If that, I 
have no anyother requirements.

Tej Arora wrote:

>Let's focus on the specific issue of RSA key transport.
>The xmlenc spec clearly allows for the possibility that the
>RSA key can be used to
>1) encrypt a key or
>2) encrypt plaintext data
>
>The xmlsec implementation has a limitation that, in the transform,
>it is not possible to determine whether we are doing (1) or (2).
>
>Is it important to know the difference?. Normally YES, but in
>this specific case, I don't think so. Let me explain.
>
>For (1), "RSA wrapping" is the more appropriate mechanism,
>and for (2) "RSA encryption" is the right choice. Encryption
>works on plaintext data from the application, and wrapping
>works on a key already known to a PKCS11 token. In our case,
>the key is initially in the form of plaintext data anyway,
>and has to be converted to a token key to do wrapping.
>Both yield the same result anyway, therefore the conclusion
>that for xmlenc purposes we're ok with just RSA encryption.
>
>Andrew, do you see any significant reason why we can't
>just use (2) always?.
>
>
>
>Aleksey Sanin wrote:
>
> >
> > >
> > > Right. But it must be known which key type in processing if it is a
> > key.
> >
> > No, in XMLEnc case, this is just binary data. The algorithm itself *does
> > not*
> > require the key type.
> >
> > >
> > > I think xmlSec do not aim to implement a crypto algorithm if
> > > neccessary. Key wrap is a algorithm thing.
> >
> > Exactly! Now look at xmlsec-openssl. AES/DES key wraps, AES and DES
> > encrytpion, DSA signatures,
> > and probably some other stuff was implemented in xmlsec only because
> > openssl did not
> > provide *exactly* the same implementation as required. In one case, it
> > was a different padding,
> > in another case, a different "magic" byte, etc. The standards are usualy
> > broad and there are a lot
> > of different options. XMLDSig/XMLEnc choose one, crypto library
> > implementors choose another.
> > And we have incompatibility.
> >
> > Again, this is not as simple as it looks like. It would be great if nss
> > implements exactly what we need!
> > Then our life would be much more simple :)
> >
> > > Surely, they are all following the same standards.
> >
> > See above.
> >
> >
> > Aleksey
> >
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
>
>
>_______________________________________________
>xmlsec mailing list
>xmlsec at aleksey.com
>http://www.aleksey.com/mailman/listinfo/xmlsec
>  
>