> > > 3) Providers of public digital signatures offer software (a > > > one-size-fits-all Java “blob”) that should add cryptography capabilities > > to > > > the operating system.
> > > > This is important. Thank you. Let me rephrase my wild guess: > > 3.1) An OS (OpenBSD or other) may have cryptography capabilities included > in the kernel. Yes. > 3.2) An OS that doesn't have cryptography capabilities included in the > kernel may provide cryptography software, not being included in the kernel, > fit and apt for use on the specific OS. This is where you seem to be missing that LOTS AND LOTS of programs use crypto from external libraries. They call openssl, they use NSS/NSPR, programs link against gnutls, java code use java libs, go code use go crypto and so on. > 3.3) Forcing the blind use of proprietary > java-crypto-one_size_fits_all-blob is technically possible, but it is a bad > practice since: > 3.3.1) it may downgrade crypto functionality existing in an OS as described > under 3.1 and 3.2 > 3.3.2) it may compromise and expose to the attacks not only the digital > signature, but the operating system itself > 3.3.3) for a number of other reasons (updates, licensing issues, etc.) Those last subpoints work both ways. A brought-along crypto primitive can be controlled by the person installing the program in ways you can't with the OS, so it is, like so much else, a tradeoff. If you don't control the OS and what crypto primitives it has, bringing along your own might be "safer" than to trust some OS to have a stable interface forever and ever. -- May the most significant bit of your life be positive.
