Aleksey Sanin wrote:
If you give people a safe with a provision to lock it, but they want to<title>
However, the very idea behind making this change is to eliminate theI don't see big difference between using private key in clear and private
"unhygenic" practice of using private keys in the clear...
key in pkcs8 file with no password or with "password" password. If someone
do not understand what is s/he doing then someone always find a way to screw up
him/herself :)
leave it unlocked, not much you can do about it :).
But if you refuse to give them a safe without a locking provision, atleast
you're doing your part in discouraging bad habits....
Agree. This change is one of those "best practices" thing, and isn't
But if you insist....I insist on keeping xmlsec backward compatible now. I don't know who use
and what kind of scripts are based on a fact that "--privkey-der" loads a clear
text private key. Changing the library/utility behaiviour w/o warning seems
wrong to me. And for me, the issue does not seem important enough to go
to xmlsec 2.0 :)
critical. To some extent it helps crypto engines, that are religious about not
supporting bad habits, leverage the test harness fully.
Nothing else.
How do --privkey-der-pkcs8 and --privkey-pem-pkcs8 sound?.What about simple "--pkcs8-pem" and "--pkcs8-der"? What else besides
private key could be there?
The difference between --privkey and --pkcs8 is marginal really.
I lean towards --privkey because it becomes immediately obvious
what the arg is. "pkcs8" may not be common knowledge.
In either case, your test scripts will need another parameter in order
to support all pvt key formats (der, pem, pkcs8 der, pkcs8 pem).
I'll send the changes in a few days.
-Tej
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Aleksey
