certutil - iPaddress SubjectAltName extension
Hi experts, although I'm pretty sure this has been asked before I could not find any pointers in the archive. What is the reason, why certutil supports 'dNSName' GeneralNames for SubjectAltName but not 'iPAddress' (RFC 3270 secion 4.2.1.7)? Especially Directory Servers (used for 'native LDAP') often use IP instead of FQDN in the SAN extension of the server cert an it's not too nice to use 'openssl' to get this. I've seen bug 396255, which suggests there was so intention to support it. TIA, Bernhard -- Painstaking Minds IT-Consulting Bernhard Thalmayr Herxheimer Str. 5, 83620 Vagen (Munich area), Germany Tel: +49 (0)8062 7769174 Mobile: +49 (0)176 55060699 bernhard.thalm...@painstakingminds.com - Solution Architect http://www.xing.com/profile/Bernhard_Thalmayr http://de.linkedin.com/in/bernhardthalmayr This e-mail may contain confidential and/or privileged information.If you are not the intended recipient (or have received this email in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS Custom Crypto Module
Is there any documentation about how to use ckfw or someone has to read and understand it from source examples erc.? -- View this message in context: http://mozilla.6506.n7.nabble.com/NSS-Custom-Crypto-Module-tp319226p319424.html Sent from the Mozilla - Cryptography mailing list archive at Nabble.com. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
The TPM is dead, long live the TEE!
Somewhat unfortunate for Microsoft and Intel who have bet the house on TPMs (Trusted Platform Modules), all their competitors in the mobile space including Google and Apple, have rather settled on embedded TEE (Trusted Execution Environment) schemes enabling systems like this: http://www.nasdaq.com/article/samsung-mobilesecurity-platform-to-be-part-of-next-android-20140625-00937 iOS: http://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf How come the competition didn't buy into the TPM? TPMs are based on a one-size-fits-all security API philosophy. Since Intel relies on external vendors supplying TPM-components this (IMHO fairly unwieldy) API must also be standardized which makes the process updating TPMs extremely slow and costly. TEEs OTOH can be fitted at any time with application-specific security APIs which both can be standardized or entirely proprietary. In fact, even third-parties can crate new security APIs using GlobalPlatform's TEE! How about security? Since there is (generally) very little consensus on these matters, I should probably not dive too deep into this :-) Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil - iPaddress SubjectAltName extension
On Mon, 2014-07-14 at 10:47 +0200, Bernhard Thalmayr wrote: What is the reason, why certutil supports 'dNSName' GeneralNames for SubjectAltName but not 'iPAddress' (RFC 3270 secion 4.2.1.7)? Do you refer to the command line parameters -7 and -8 ? I don't know why this subset was chosen in the past. However, just recently we added support for additional SAN variations (in version 3.16.2), which provides the new parameter --extSAN. Can you try it? If it doesn't work as expected, please let us know. Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: The TPM is dead, long live the TEE!
On 12/07/2014 05:33, Anders Rundgren wrote:
Somewhat unfortunate for Microsoft and Intel who have bet the house
on TPMs (Trusted Platform Modules), all their competitors in the
mobile space including Google and Apple, have rather settled on
embedded TEE (Trusted Execution Environment) schemes enabling systems
like this:
http://www.nasdaq.com/article/samsung-mobilesecurity-platform-to-be-part-of-next-android-20140625-00937
iOS:
http://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf
How come the competition didn't buy into the TPM?
TPMs are based on a one-size-fits-all security API philosophy. Since
Intel relies on external vendors supplying TPM-components this (IMHO
fairly unwieldy) API must also be standardized which makes the process
updating TPMs extremely slow and costly.
TEEs OTOH can be fitted at any time with application-specific security
APIs which both can be standardized or entirely proprietary. In fact,
even third-parties can crate new security APIs using GlobalPlatform's
TEE!
How about security? Since there is (generally) very little consensus
on these matters, I should probably not dive too deep into this :-)
Anders
Perhaps for another interesting example of the mobile industry's
legendary security foresight you might try to find a transcript or notes
from a talk two gentlemen by the names of Josh Thomas and Nathan Keltner
gave at recon in montreal this year titled here be dragons: a bedtime
tale for sleepless nights. In it, they called out how terrible
inter-vendor coordination coupled with allowing several people to add
their own APIs to the trust zone code (in that particular case, a DRM
API) resulted in a trivial and complete read/write what where
vulnerability in the trust zone (as implemented by one particular
vendor), followed by code execution.
I really don't think mobile didn't do this therefore it's {not
relevant,a bad idea} is valid. The TEE has a different set of
problems, but it certainly has them, and I think it's managed to
embarrass a lot more people than TPM has during its tenure. Also, the
platforms are only converged on the surface (if that).
--Falcon K.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil - iPaddress SubjectAltName extension
Thanks a lot for the details Kai, much appreciated. Indeed I was referring to options '-7', '-8' as they are decribed at https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_certutil I was not aware of '--extSAN' as it seems to be missing from the above doc. Thanks for pointing it out. I will give it a shot. Is there any documentation available for '--extSAN' parameter? Mr. Google did not find any helpful resource. Thanks again, Bernhard Am 7/14/14 8:11 PM, schrieb Kai Engert: On Mon, 2014-07-14 at 10:47 +0200, Bernhard Thalmayr wrote: What is the reason, why certutil supports 'dNSName' GeneralNames for SubjectAltName but not 'iPAddress' (RFC 3270 secion 4.2.1.7)? Do you refer to the command line parameters -7 and -8 ? I don't know why this subset was chosen in the past. However, just recently we added support for additional SAN variations (in version 3.16.2), which provides the new parameter --extSAN. Can you try it? If it doesn't work as expected, please let us know. Kai -- Painstaking Minds IT-Consulting Bernhard Thalmayr Herxheimer Str. 5, 83620 Vagen (Munich area), Germany Tel: +49 (0)8062 7769174 Mobile: +49 (0)176 55060699 bernhard.thalm...@painstakingminds.com - Solution Architect http://www.xing.com/profile/Bernhard_Thalmayr http://de.linkedin.com/in/bernhardthalmayr This e-mail may contain confidential and/or privileged information.If you are not the intended recipient (or have received this email in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
