Hi Martin,

- currently it is only possible to get the own CA certificate from
  the DB, isn't it? The var/crypto/chain directory may contain
  the required certificates, but it is not really enforced, right?
  Do you think it is sensible to construct the keystores based
  on the CA certs that are available, e. g. if the other CA certs
  are found in var/crypto/chain then use them, otherwise only include
  cert and cacert in the keystore.

The whole chainhandling is not really good implemented at the moment

- due to limitations of the &*$ Java JCE stuff it is not possible
  to handle encrypted PKCS#8 keys, so I have to provide an unencrypted
  key. I will have to write it to a temp file (mode 400) and delete
  it immediately after the operation. OK?

Ouch...
I see some problems on writing confident material on the disk because even on *nix'es you can try to recover files - I had this idea some time ago: Whats about creating a special Ram-Disk or Crypto-Loop device to use as temporary "file" storage ?

- somehow I have to provide the Java tool with the passwords for
  key and keystore. This is currently done on the commandline.
  Drawback: it briefly shows in the ps command.
  Another approach would be to pipe the stuff into the Java command
  via STDIN. Environment is not accessible by Java, AFIK.

So Password in the ps command is a NOGO for me, because this can be seen by ANY user - I see a security breach in this....

2. Random pin generation (RFE 1009984)

idea is ok, I see one issue - at least the IE is known to have a strange caching behaviour - is it possible to grab the displayed pin my a kind of "form reload" attack ? Had such problems some time ago with unencrypted pages, I dont know if the IE handels this better on secure connections

From my point of view it is sufficient to add this to the basic_csr - the PIN for the other request is nearly useless - we can think about using the Pin for revokation, so it would make sense again - but thats another issue

Oliver
--
Diese Nachricht wurde digital unterschrieben
oliwel's public key: http://www.oliwel.de/oliwel.crt
Basiszertifikat: http://www.ldv.ei.tum.de/page72

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



Reply via email to