[xmlsec] nss updates
tejbiz at aol.com
Tue Jul 29 10:06:29 PDT 2003
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
> No, in XMLEnc case, this is just binary data. The algorithm itself *does
> 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.
> xmlsec mailing list
> xmlsec at aleksey.com
More information about the xmlsec