[Image] --------------------------------------------------------------------------- SecuDE - FAQ --------------------------------------------------------------------------- Contents: [Image] What is this SecuDE? [Image] How can I get the SecuDE sources and binaries? [Image] How can I get subscribed to mail-list 'secude'? [Image] Current Release and Patch Level? [Image] What are the supported platforms? [Image] Who may use SecuDE? [Image] What are the plans for further development of the SecuDE package ? [Image] Where can I find further information or sites dealing with security? [Image] How interoperable is SecuDE? [Image] How can (related) RFCs be achieved? [Image] Where can I find more documentation of SecuDE? [Image] Where can I find some examples? [Image] How is the SecuDE API structured? [Image] Is there a performance evaluation of the package? [Image] How can I become a certified User? [Image] Can I directly use prototype (self signed) certificates? [Image] Can an one-keypair-PSE distinguish signature/encryption certificates? [Image] Can I store and use several RSA key pairs in one PSE? [Image] Where are the Cross Certificates gone to? [Image] How should process certification be initiated? [Image] Where is a software PSE located ? [Image] Where is a SmartCard PSE located ? [Image] How can I add aliases to the system alias database? [Image] Can I access my CA over a LAN filesystem? [Image] What is the status of the PC version? [Image] Is there any SmartCard solution in SecuDE for PCs? [Image] How can I use SecuDE in MS-Windows-Applications? [Image] Which ISODE version is supported? [Image] Are there information in detail about the strong authentication QUIPU? [Image] How can I replace QUIPU by another X.500 product? [Image] Does anybody know where can I get the syntax of the attribute type "BlackList"? [Image] How do I install the object class strongAuthenticationUser"? [Image] What are the initial values for strong authentication attributes? [Image] How can I modify the userCertificate attribute? [Image] How can one put user certificate into the AF-DB directory? [Image] How can I use SmartCards when I run SecuDE processes remotely? [Image] Where can I get the Starcos documentation? [Image] Who provides the GAO/GMD SmartCard package Starcos? [Image] Are there any incompatibilities between SecuDE-PEM and TIS-PEM? [Image] Is there a way to avoid entering the PIN when running SecuDE utilities from a script? [Image] Why can the person who PEM-encrypted a message also be able to decrypt it? [Image] What does a PEM certification request command look like? [Image] Is SecuDE-PEM able to read MIME-PEM? [Image] Does a MH version exist exploting SecuDE4.4? [Image] How can I create certificates to communicate with RIPEM? [Image] Are there statically linked binaries of XMst available? [Image] How can I generate the xmst.uid module under Solaris 2.4? ------------------------------------------------------------------------------- Questions and Answers: [Image] What is this SecuDE? [Image] SecuDE (= Security Development Environment) is a portable general-purpose security toolkit. It provides a security API (C library) with functions for key generation, en/decryption, signature and verification, X.500 access, and more. Several utilities for maintaining personal and certification authority environments, a Internet PEM filter, and a Motif Tool are part of the package. [Image] How can I get the SecuDE sources and binaries? [Image] SecuDE can be obtained from our anonymous FTP server. We have placed the complete source package and some executables there, furthermore some related tools and information can be downloaded from there. [Image] How can I get subscribed to mail-list 'secude'? [Image] For electronic mail discussions about SecuDE use the Internet address secude@darmstadt.gmd.de To get added to the list send an informal mail to secude-request@darmstadt.gmd.de [Image] Current Release and Patch Level? [Image] The current release is SecuDE-4.4b0 with patch level 002, see README_SECUDE.patches. [Image] What are the supported platforms? [Image] All programs of SecuDE are written in C except a small number of long- integer arithmetic programs which are necessary for RSA and DSA. These programs are written in assembler language (assembler programs for SUN SPARC, HP 9000, Motorola 680x0 for SUN/3 and Apollo Domain WS3xx and WS4xx and INTEL 286/386 are part of the package). C-only versions of RSA and DSA are contained in the package, too. SecuDE contains some third-source software, for instance ASN.1 functions from ISODE-ICR1.1v3. It uses the md2, md4 and md5 programs from RFC 1319 - 1321. The package is self-contained except for the X.500 DUA functionality which requires a QUIPU-ICR1.1v3 installation (libisode.a). SecuDE can be installed on SUN/3 or SUN/4 systems with SunOS 4.1.2, SunOS 4.1.3 or Solaris 2.x, on HP 9000 workstations with HP-UX, DEC Alpha workstations with OSF1, on Silicon Graphics with IRIX, on Apollo Domain/IX systems, and under MS-DOS (the latter without integrated X.500 DUA und without SmartCard support; a GNU gcc installation is needed on your MS-DOS system in order to install SecuDE-4.4 from the source; Windows DLLs are under development). It works under LinuX, too. The installation on other Unix platforms should be possible with minor effort. [Image] Who can use SecuDE? We have read that the new release of SecuDE can be used free of charge only for non commercial purposes. Furthermore, being a public institution, we have problems to install and use products that have no guarantee. Therefore we would like to know: * Can the use of SecuDE by the EU Social Security Institutions be considered as non-commercial ? * Are you able to guarantee in some way SecuDE ? * If yes, what will be the charge for this service ? [Image] The current version of Secude has been distributed as a free public domain package. It can be used as it is, with no commercial restrictions except that copyright remarks retain visible. Off course no warranty is granted under such conditions, and support will be limited. We have not decided yet whether this will keep true with further releases. It might be the case that further releases will be available under licence agreements and with improved support conditions. There are no further restrictions from our side. If your product incorporates RSA functionality, you should pay attention to the patent situation in USA in the case that you plan to export your product to the US. A general issue are national export regulations for products with cryptographic functionality. [Image] What are the plans for further development of the SecuDE package ? [Image] Technically, SecuDE-5.0 will include * a transition from ISODE-8 to IC-R1 * GSSAPI * New SmartCard technology (with RSA SmartCards and cheaper SmartCard readers) * More Motif-based tools GSSAPI is a bit unclear in the moment because I don't know yet what it precisely means. The GSSAPI itself is also still under development. [Image] Where can I find further information or sites dealing with security? [Image] Lots of documents and software documentation can be found on our FTP server! [Image] There is a very interesting article about PEM written by one of the authors of the PEM RFCs, Stephen Kent, although this article is not specific to SecuDE but deals with Privacy Enhanced Mail in general: Stephen T. Kent: Internet Privacy Enhanced Mail appeared in: Communications of the ACM Vol.36, No. 8, August 1993, pp. 48-60 See our Security Home Page for more information and sites! [Image] How interoperable is SecuDE? We are developing an open application that needs some security functionalities (like encryption and electronic signature). This is a client-server application and the server uses SecuDE to encrypt information and to manage keys and certificates. Our problem is interoperability between the server environment (UNIX using SecuDE) and other possible client environments (DOS, UNIX, and so on) using different security toolkits. (We are particularly interested in the interoperability between the UNIX server with SecuDE and a DOS client). Did anyone face interoperability problems in security environment? Our specific questions are: * Which are the security toolkits that are able to interoperate? (exchange keys, verify signatures generated by different toolkits, decode messages encrypted by different toolkits) * Which are the toolkits of security that are able to interoperate on the basis of the international standards (X.509, RFC 1421 - 1424)? * Is there any mechanism other than PEM that can assure interoperability? [Image] ??? [Image] How can (related) RFCs be achieved? [Image] Lots of RFC's can be found on our FTP server! [Image] Use RFC-Info by sending email messages to RFC-INFO@ISI.EDU. * To get a specific RFC send a message with text as follows: Retrieve: RFC Doc-ID: RFC1500 This gets RFC 1500. All RFC numbers in the Doc-Id are 4 digits (RFC 791 would be Doc-ID: RFC0791). * To get a specific FYI send a message with text as follows: Retrieve: FYI Doc-ID: FYI0004 * To get a list of available RFC's that match a certain criteria: LIST: RFC Keywords: Gateway Returns a list of RFC's with the word Gateway in the title or specified as a keyword. * To get the Index of all RFCs published: HELP: rfc_index * To get information about other ways to get RFCs, FYIs, STDs, or IMRs. HELP: ways_to_get_rfcs HELP: ways_to_get_fyis HELP: ways_to_get_stds HELP: ways_to_get_imrs * To get help about using RFC-Info: HELP: help HELP: topics [Image] Where can I find more documentation of SecuDE? [Image] See our SecuDE Documentation Volumes 1 - 3. Our WWW Pages are under wild development... [Image] Where can I find some examples? I think the documentation doesn't explain HOW TO use SecuDE, only function interfaces... [Image] The current documentation is indeed a manual-style paper load which is good when you roughly know what to ask for, but which is difficult to deal with when you are starting. We are planning to have a tutorial-style doc including examples with SecuDE-5.0 because we plan to change some function inter- faces [Image] How is the SecuDE API structured? [Image] ______________________________________________________________________ | | | | | | | util | pkcs-util | | | | | (executables) | (executables) | | | | |========================================|=============================| | | | | | c | pem | pkcs *) | | r | | | | y | ________________________________|___________ | | p | | | | | t | | sec af auxil | | | | | | | | t | | _____________________________________|_________________| | e | | | | | | s | | | sca | encode | | t | | | | | |___|___|______|___________________________|___________________________| | | | | crypt | isode | | | | |_____________________________________________________|________________| *) PKCS will be part of SecuDE-4.5 [Image] Is there a performance evaluation of the package? And eventually some test metrics in keys management and data encryption/decryption? [Image] The command "algs -U" will produce performance figures of all algorithms implemented in SecuDE. Please note that these figures are depending on how you compiled SecuDE (with or without optimizer, which compiler etc.). After a new installation of SecuDE, this command is also a good test to check whether it works well. For each type of algorithm, appropriate operations (encryption/decryption or sign/verify) are performed (in case of asymmetric algorithms for different keysizes),and the results are checked. I append some example output of the command algs -U, produced on a Sparc 10/40 and compiled with gcc with optimizer. Times are in seconds. SYM_ENC Algorithms ================== ___________________________________________________________________________ DES-ECB OID { 1 3 14 3 2 6 } NULL parameter Encr (100 Kbytes): 0.823 Decr (100 Kbytes): 0.816 ___________________________________________________________________________ DES-CBC OID { 1 3 14 3 2 7 } Parameter DES-IV (default zeros) Encr (100 Kbytes): 0.855 Decr (100 Kbytes): 0.865 ___________________________________________________________________________ DES-EDE OID { 1 3 14 3 2 17 } NULL parameter Encr (100 Kbytes): 2.431 Decr (100 Kbytes): 2.423 ___________________________________________________________________________ IDEA OID { 1 3 36 3 1 30 } NULL parameter Encr (100 Kbytes): 0.641 Decr (100 Kbytes): 0.639 ___________________________________________________________________________ ASYM_ENC Algorithms =================== ___________________________________________________________________________ RSA OID { 1 2 840 113549 1 1 1 } NULL parameter Encr ( 512 bits): 0.014 Decr ( 512 bits): 0.182 Encr ( 640 bits): 0.020 Decr ( 640 bits): 0.320 Encr ( 768 bits): 0.028 Decr ( 768 bits): 0.498 Encr (1024 bits): 0.047 Decr (1024 bits): 1.136 ___________________________________________________________________________ rsa OID { 2 5 8 1 1 } Parameter Keysize (default 512) Encr ( 512 bits): 0.013 Decr ( 512 bits): 0.181 Encr ( 640 bits): 0.020 Decr ( 640 bits): 0.319 Encr ( 768 bits): 0.027 Decr ( 768 bits): 0.498 Encr (1024 bits): 0.047 Decr (1024 bits): 1.087 ___________________________________________________________________________ HASH Algorithms =============== ___________________________________________________________________________ md2 OID { 1 2 840 113549 2 2 } NULL parameter Hash (100 Kbytes): 1.079 ___________________________________________________________________________ md4 OID { 1 2 840 113549 2 4 } NULL parameter Hash (100 Kbytes): 0.028 ___________________________________________________________________________ md5 OID { 1 2 840 113549 2 5 } NULL parameter Hash (100 Kbytes): 0.035 ___________________________________________________________________________ sha OID { 1 3 14 3 2 18 } NULL parameter Hash (100 Kbytes): 0.039 ___________________________________________________________________________ SIG Algorithms ============== ___________________________________________________________________________ dsaWithSHA OID { 1 3 14 3 2 13 } NULL parameter Sign ( 512 bits): 0.226 (total), 0.186 (DSA), 0.039 (SHA) Veri ( 512 bits): 0.379 (total), 0.337 (DSA), 0.039 (SHA) Sign ( 640 bits): 0.293 (total), 0.253 (DSA), 0.039 (SHA) Veri ( 640 bits): 0.539 (total), 0.498 (DSA), 0.039 (SHA) Sign ( 768 bits): 0.387 (total), 0.347 (DSA), 0.039 (SHA) Veri ( 768 bits): 0.735 (total), 0.694 (DSA), 0.040 (SHA) Sign (1024 bits): 0.569 (total), 0.529 (DSA), 0.039 (SHA) Veri (1024 bits): 1.163 (total), 1.122 (DSA), 0.039 (SHA) ___________________________________________________________________________ md2WithRsaEncryption OID { 1 2 840 113549 1 1 2 } NULL parameter Sign ( 512 bits): 1.264 (total), 0.182 (RSA), 1.081 (MD2) Veri ( 512 bits): 1.096 (total), 0.014 (RSA), 1.081 (MD2) Sign ( 640 bits): 1.401 (total), 0.321 (RSA), 1.079 (MD2) Veri ( 640 bits): 1.101 (total), 0.021 (RSA), 1.079 (MD2) Sign ( 768 bits): 1.620 (total), 0.538 (RSA), 1.081 (MD2) Veri ( 768 bits): 1.109 (total), 0.028 (RSA), 1.079 (MD2) Sign (1024 bits): 2.167 (total), 1.087 (RSA), 1.079 (MD2) Veri (1024 bits): 1.129 (total), 0.048 (RSA), 1.079 (MD2) ___________________________________________________________________________ md4WithRsaEncryption OID { 1 3 14 3 2 4 } NULL parameter Sign ( 512 bits): 0.211 (total), 0.183 (RSA), 0.028 (MD4) Veri ( 512 bits): 0.043 (total), 0.014 (RSA), 0.028 (MD4) Sign ( 640 bits): 0.349 (total), 0.321 (RSA), 0.027 (MD4) Veri ( 640 bits): 0.050 (total), 0.021 (RSA), 0.028 (MD4) Sign ( 768 bits): 0.526 (total), 0.498 (RSA), 0.028 (MD4) Veri ( 768 bits): 0.058 (total), 0.029 (RSA), 0.028 (MD4) Sign (1024 bits): 1.117 (total), 1.088 (RSA), 0.028 (MD4) Veri (1024 bits): 0.078 (total), 0.048 (RSA), 0.028 (MD4) ___________________________________________________________________________ md5WithRsaEncryption OID { 1 2 840 113549 1 1 4 } NULL parameter Sign ( 512 bits): 0.217 (total), 0.182 (RSA), 0.034 (MD5) Veri ( 512 bits): 0.050 (total), 0.014 (RSA), 0.034 (MD5) Sign ( 640 bits): 0.356 (total), 0.321 (RSA), 0.034 (MD5) Veri ( 640 bits): 0.056 (total), 0.021 (RSA), 0.034 (MD5) Sign ( 768 bits): 0.535 (total), 0.499 (RSA), 0.034 (MD5) Veri ( 768 bits): 0.064 (total), 0.028 (RSA), 0.034 (MD5) Sign (1024 bits): 1.123 (total), 1.088 (RSA), 0.034 (MD5) Veri (1024 bits): 0.084 (total), 0.048 (RSA), 0.034 (MD5) ___________________________________________________________________________ [Image] How can I become a certified User? [Image] There are two ways (assuming that you know under which CA you want to be placed): * The user generates a new PSE with 'psecreate' or a new key pair with 'genkey'. The self-signed prototype certificate must be sent to the CA in a signed mail (e.g. PEM MIC-CLEAR..., send it with your Mail User Agent), a so-called 'Certification Request'. The CA may answer with a PEM 'Certification Response' which contains a new unique certificate. The user has to de-enhance the mail (using PEM SCAN...), whereby the new objects (certificate, forward certification path, root's public key) are inserted into the PSE. * The CA generates complete and certified User PSEs which have to transported to the user. This must be done in a secure way, of course, e.g. with a floppy disk or a SmartCard. The PIN must be transported in a different way, e.g. with snail mail. It is recommended to change the PIN immediately during PSE installation! [Image] Can I directly use prototype (self signed) certificates? I create two users with their own PSEs, say user Adam and user Eve. Adam has only one key pair (to be able to sign files) and Eve has two key pairs (the signature pair and the encryption pair). Let's assume that Eve generates a prototype for her encryption public key and a prototype for her signature public key. I can write this prototypes in objects of Adam's PSE via "psemaint" and "write". After this I use the command "addpk" with the object that contains the prototype for the signature key. Success: I can look at the PKList and the key has been added. But, when trying "addek" from the object that contains the encryption public key I get an error: Can't add cert to EKList ERROR in af_pse_add_PK: (102) Don't add key to PKList because tbs with same issuer and serialnumber or with same subjectPK exists already It seems that "addek" was trying to add the encryption key to PKList (not EKList). Why can't you insert both the signature and the encryption prototype into Adam's PKList? [Image] Prototype certificates always have the following structure: SubjectName: IssuerName: SerialNumber: 0 (decimal) It's self-signed, not issued by a CA. So it doesn't make too much sense to insert such a prototype in any list of TRUSTED public keys. Prototype certificates are used to be sent in a certification request to your CA, and are replaced by a regularily signed certificate taken from the received certification response. Eve's certificates have the same Subject/Issuer/SerialNumber combination! A certification response would contain two certificates with different, since unique SerialNumbers. [Image] Can an one-keypair-PSE distinguish signature/encryption certificates? Psemaint's "toc" lists the objects and there is PKList and there isn't EKList, but, if (outside psemaint) I issue a "pklist -e" command the answer is: ******************** EKList **************** 1. ---------------------------------- and the signature public key of Eve! [Image] Because 1. the text output was wrong (it's been changed to "Trusted SIGNATURE/ENCRYPTION keys"), and 2. a single key pair PSE doesn't care about what the certificated key was created for originally. [Image] Can I store and use several RSA key pairs in one PSE? I want to have another key pair (for another user-id) in the same PSE as my (other) key is. I have a key for the user-id I use most, but I'd like to have one for another userid too. I did have a look at genkey, but genkey can't do it for me. [Image] SecuDE doesn't support the use of more than one RSA keypair (secret key and certified public key) within one PSE. A PSE (Personal Security Environment) should belong to one person/role and one person/role should only use one secret RSA key for signing documents. If you need another keypair to distinguish under which userid you sign a document, you should generate a further PSE for this userid. [Image] Where are the Cross Certificates gone to? [Image] SecuDE doesn't support Cross Certificates anymore. The maintenance is very complicated if they are heavily used, the clear construction of a certification infra structure may become undermined. [Image] How should process certification be initiated? I want to run a CA as a process that can certify other processes. The problem I have is how can the CA process be sure of the identity of the calling process (the one that wants to be certified). Observe that the calling process has no public key that can be used in the identification process. The user that starts the process should ont need to enter any password either. [Image] The problem which you raise exists also with normal users who are to be certified by a CA. The assurance of a real identity of any client to a CA (if another CA or not) is generally a problem which must be solved outside of the certification process. One way is to add other communication steps, preferrably outside of computer communication. E.g., the CA could initiate another session and send the certificate in that self-initiated session, after it has made sure who the other is (by ordinary paper mail, telephone calls, face-to-face-meetings, ink signatures etc.) [Image] Where is a software PSE located ? [Image] The name of the PSE is the path of the directory where the PSE is located. If the name is not given absolute, it is used relativ to the path in the environment variable HOME.. The default PSE has the name .pse , so the PSE resides in $HOME/.pse . A default CA-PSE has the name .ca . On Unix systems the HOME variable is set automatically. Under MS-DOS you have to set it manually if you want to use relative or default names. The default names are PSE and CA. Additionally you can set the variable USER to the users name. If someone creates a new PSE the owner is set to it's value. [Image] Where is a SmartCard PSE located ? [Image] In the SmartCard environment currently supported by SecuDE, a PSE is splitted into two parts. The main PSE objects (secret and certified public key, root public key, forward certification path, QUIPU password) are stored on the chipcard file system. Any other additional objects are placed in a (automatically generated) software appendix. [Image] How can I add aliases to the system alias database? I only can access my PSE object AliasList. [Image] No, there isn't. The system alias database should only be maintained by your local SecuDE administrator who has write access to the .alias*-files. This will be the job of the (site) CA, of course! The main idea is that the CA adds a set of aliases for each user that has been certified the first time. [Image] Can I access my CA over a LAN? Or must they be on the same filesystem as the PSE ? [Image] If you have a filesystem which goes across a LAN (e.g. NFS) this shouldn't cause any trouble. [Image] What is the status of the PC version? Will the PC version include the same functionality as the UNIX version ? [Image] SecuDE-4.4b0 has been ported to MS-DOS, a GNU gcc installation is needed on your MS-DOS system in order to install it from the source; all functions but the integrated X.500 DUA (because that would mean that we had to port the QUIPU code) and SmartCard support are included. Windows DLLs will be available in one of the next minor releases (I hope the OS/2 porting can be done quickly, too!). SecuDE also works under LinuX. [Image] Is there any SmartCard solution in SecuDE for PCs? [Image] Not yet. [Image] How can I use SecuDE in MS-Windows-Applications? [Image] Since there is no Windows DLL available yet, SecuDE utilities like PEM only can be started as a separate DOS shell process. The communication between application and SecuDE child is to be done via temporary files, other parameters can be set in the shell's command line. To prevent a child from prompting for user PINs (e.g. if running invisible in the background) the environment variable USERPIN is evaluated by SecuDE utilities; it can be read by a Windows dialog before. [Image] Which ISODE version is supported? I saw that the new SecuDE release 4.4 dropped the support for ISODE 8.0. For that reason (and others...) I am about to get and install an IC release of ISODE. From the ftp-server at isode.com I learned that there are newer versions of ISODE than the ICR1.1v3 version that is mentioned in the README file of Secude 4.4. Are there any reasons why I shouldn't take the newest version of IC ISODE (currently ICR2.1v2)? [Image] ICR2 is a major change over ICR1. SecuDE-4.4.a0 which is currently on our server supports ICR1.1v3 and does not immediately interwork with ICR2.1v2. However, we are working on it, and the next version SecuDE-4.4.b0 will support ICR2.1v2. [Image] Are there information in detail about the strong authentication QUIPU? [Image] Have a look at our SecuDE Documentation Volume 3: Security Applications Guide, chapters 1 + 2 [Image] How can I replace QUIPU by another X.500 product? [Image] In SecuDE-4.2, the access to X.500 Directories using QUIPU routines is spread over many places. The effort needed to replace QUIPU by another system will be high. Since SecuDE-4.3, the X.500 access is concentrated in a single subroutine where all the mapping to QUIPU routines is done. You would probably have to rewrite this routine entirely. It should be possible in a reasonable amount of time. [Image] Does anybody know where can I get the syntax of the attribute type "BlackList"? Attributes "revokedCertificateList" and "revokedAuthorityList" are structured according to that syntax. [Image] The attribute type BlackList is not used in SecuDE. Look for the type Certificate Revocation List which is part of the PEM RFCs. [Image] How do I install the object class strongAuthenticationUser"? I have compiled and installed both SecuDE 4.2 and the security enhanced version of ISODE 8.0 and have generated both my Root-CA, and PSEs for my org's DSA and myself, apperently with no real problems (I can sign a file using my PSE and can verify it while running as my DSA). Now, I'd like to add the certificates to the X.500 directory, but can't find an explaination on how to do this (or did I just miss it?). I currently have an entry in the directory, but how do I "upgrade" this entry to add object class "strongAuthenticationUser"? If I just bind using dish and say "modify", I can add the object class, but, when I save it complains that there is no attribute "UserCertificate". Is there some command that will extract my certificate from my PSE into a form that I can then load into the directory using an entry such as "UserCertificate = {FILE}./cert"? [Image] One possible solution for this problem is to create an DEFAULT-entry "userCertificate" whithin your o=ECRC\EDB This entry looks in my ../o=GMD/EDB like: iattr= strongAuthenticationUser $ DEFAULT ( userCertificate= md2WithRSAEncryption#{ASN}050000#\ 000000001111111122222222333333330000000011111111222222223333333300000000111111\ 11222222223333333300000000111111112222222233333333#c=DE@o=GMD#\ c=DE@o=GMD@l=Darmstadt@cn=dummyUserCertificate#\ md2WithRSAEncryption#{ASN}050000#\ 0#0#000000000000Z#111111111111Z#\ rsa#{ASN}0202020000#\ 304802410089815b6a75fb2ca459494f200355eb7acef052b63239d7a82a0a5303973dcf1793ac\ 3ab84d01c84c47704dd70b18a4bd74687448009fa17e048bbcfb665101630203010001# ) You only have to modify the DN of this entry, it should be obviously, that this entry is really a DUMMY. But other "real-default" Certificates are possible. Now your are able to add for each user the attribute "strongAuthenticationUser". For all children of this EDB-entry with attribute "strongAuthenticationUser" is this the DEFAULT-userCertificate. If the child own an real "userCertificate", you can use psemaint to add the real Certificate. This works with ICR1-installation of ISODE and SecuDE 4.2 to 4.4b0, i think this will also work with ISODE 8.0. [Image] What are the initial values for strong authentication attributes? I am trying to setup a CA infrastructure for use with PEM around the ISODE 8.0/QUIPU and Secude 4.3 software. As I understood, I have to define an entry with objectclass 'organizationalUnit & certification- Authority' for the CA and one with objectclass 'strongAuthenticationUser' for every user planning to use PEM. When I use dish to define these entries, it seems that I have to give some initial value for the certificate related attributes. If I don't, dish reports an 'object violation' error and the isode dsap logfile reports that these attributes must have a value. Since I will be using Secude for the management of certificate related stuff, it will be the secude software that fills in the actual values for these attributes. What value should I provide? Is there something like a null-value or dummy value that I can use initially and then replace it with the real thing using cacreate or psemaint? [Image] 1. Editing a CA entry (with the directory shell dish command "modify"): If your DSA does not know the object class "passwordCertificationAuthority" yet edit the oidtables: oidtable.oc: ############################################################################### # locally defined object classes # (this section is usually empty...) ############################################################################### passwordCertificationAuthority: teletrust-oc.1 : certificationAuthority : : oldCertificateList, pemCRL oidtable.gen: ############################################################################### # locally defined generic objects # (this section is usually empty...) ############################################################################### teletrust: identifiedOrganization.36 teletrust-attr: teletrust.4 teletrust-oc: teletrust.7 oidtable.at: ############################################################################### # locally defined object attributes # (this section is usually empty...) ############################################################################### pemCRL: teletrust-attr.1 :pemCRL_syntax oldCertificateList: teletrust-attr.2 :OldCertificateList Now enhance the "objectClass" attribute with "certificationAuthority" and "passwordCertificationAuthority": objectClass= top & organizationalUnit & certificationAuthority & quipuObject & passwordCertificationAuthority Finally set the MUST attributes "cACertificate", "certificateRevocationList" and "authorityRevocationList" to the following dummy values: authorityRevocationList= md2WithRSAEncryption#{ASN}050000#\ c=GB@o=University College London@ou=Computer Science@ou=PASSWORD@cn=osisec#\ md2WithRSAEncryption#{ASN}050000#\ b210a605af235ea57bd614ec9ba5471ff91854d67404ec1f1249418f7e9c538161600015634f91\ f3a1d88c9fb110641806dba8c2cef678e8ec40a4475f64e571#930428103910Z certificateRevocationList= md2WithRSAEncryption#{ASN}050000#\ c=GB@o=University College London@ou=Computer Science@ou=PASSWORD@cn=osisec#\ md2WithRSAEncryption#{ASN}050000#\ b210a605af235ea57bd614ec9ba5471ff91854d67404ec1f1249418f7e9c538161600015634f91\ f3a1d88c9fb110641806dba8c2cef678e8ec40a4475f64e571#930428103910Z cACertificate= md2WithRSAEncryption#{ASN}050000#\ 77e80d0a5837f37bccbb3f79807139563fd3161d5793245901a4a1b78ab806b3ef4f2f5aa3b565\ 271fd95e9126d23172cbdc9bb710d505c4cb8b17370366266a#cn=proto#\ cn=proto#\ md2WithRSAEncryption#{ASN}050000#\ 0#14#930929152457Z#940929152457Z#\ rsa#{ASN}0202020000#\ 30480241008509eea52929e1197a08c70d09f31d9307c1d8002cd3608ace933579e217c7641201\ db4821aa3be7be5ec36fc0dc181c841ef0cea1b6cd93f056e9ef03e181a90203010001# 2. Editing a User entry: Enhance the "objectClass" attribute with "strongAuthenticationUser". Set the MUST attribute "userCertificate to the dummy value: userCertificate= md2WithRSAEncryption#{ASN}050000#\ 77e80d0a5837f37bccbb3f79807139563fd3161d5793245901a4a1b78ab806b3ef4f2f5aa3b565\ 271fd95e9126d23172cbdc9bb710d505c4cb8b17370366266a#cn=proto#\ cn=proto#\ md2WithRSAEncryption#{ASN}050000#\ 0#14#930929152457Z#940929152457Z#\ rsa#{ASN}0202020000#\ 30480241008509eea52929e1197a08c70d09f31d9307c1d8002cd3608ace933579e217c7641201\ db4821aa3be7be5ec36fc0dc181c841ef0cea1b6cd93f056e9ef03e181a90203010001# End the "modify"-operation. The attributes "certificateRevocationList" and "authorityRevocationList" keep their dummy values, since SecuDE does not support these types. Therefore we provide "pemCRL" which is the black list conform to RFC1422. The dummy certificates in "userCertificate" and "cACertificate" have to replaced by valid certificates, e.g. using the SecuDE utility "psemaint": Call 'enter' and 'remove' successively. [Image] How can I modify the userCertificate attribute? I cannot remove or enter a Certificate into my Directory entry with psemaint until I change the ACL to "everybody writes everything" with dish. AUTHLEVEL is not set. The output is: ... Binding as *** Security error - Access rights *** Directory operation (X.500) f a i l e d. ERROR in af_dir_delete_Certificate: (-268439456) Can't modify attribute userCertificate of entry <> ERROR in af_access_Directory: (-268439456) Can't modify attribute userCertificate of entry <> Directory operation (AF-DB) f a i l e d. ERROR in af_afdb_delete_Certificate: (6) Certificate (to be deleted) not found ERROR in af_dir_delete_Certificate: (-268439456) Can't modify attribute userCertificate of entry <> ERROR in af_access_Directory: (-268439456) Can't modify attribute userCertificate of entry <> [Image] Changes in a user's entry only can be made using "simple authentication", that is access control with a password. In psemaint, this mode is enabled by the toggle "authsimple". If a PSE object "QuipuPWD" exists it is used for this purpose. It only works if "QuipuPWD" and "userPassword" in the user's DSA-entry are identical. [Image] How can one put user certificate into .af-db directory? Is there some utility for this or do I have to create the correct subdirectory manualy? [Image] Indeed you have to create the user entry (which is the subdirectory with the name of the last component of the user's DName) first before you are able to enter certificates and the like. This corresponds to the X.500 Directory where a DSA manager has to create the user's entry first before the user can access. The only exceptions are the utilities 'gen_pse' and 'create_TestTree'. [Image] How can I use SmartCards when I run SecuDE processes remotely? [Image] The SmartCard-Terminal must be plugged in the machine where the process runs. SecuDE does not support a RPC mechanism or something comparable. [Image] Where can I get the Starcos documentation? I have read your STARCOS manual Volume 2 that I have found on your ftp server. I would like to get also volumes 1, 3, and 4, but I did not find them. [Image] This documentation is a product of our cooperation with the firm G&D. At present, volume 1, 3, and 4 are not public. [Image] Who provides the GAO/GMD SmartCard package Starcos 1.1? We would like to have some information about the GAO/GMD SmartCard package Starcos 1.1 and in particular about: * Starcos terminal * Starcos SmartCard * Their costs * Documentation about them (we posses the vol.2 STARCOS - Smartcard Application Package - Specification of the Smartcard Application Interface) * Permissions to use Starcos package [Image] The sale of the Starcos SmartCards and the SmartCard terminals is done by our cooperation partner G&D. Unfortunately you can't reach them via e-mail. Here is their address: Giesecke & Devrient z.H. Herr Froehlich Prinzregentenstrasse 159 Postfach 80 07 29 D-81607 Muenchen If you want to order SmartCards or the SmartCard terminal you have to mention that you want to use these devices together with the SecuDE package from GMD. [Image] Are there any incompatibilities between SecuDE-PEM and TIS-PEM? I received a copy of the IPRA CRL via WWW (http://bs.mit.edu:8001/ipracrl.html) and tried to process it with my PEM application. PEM answered with the error message "Header Field expected" although the CRL below seems fine (according to RFC1424). [Image] It's fixed in SecuDE-4.4b0. [Image] Is there a way to avoid entering the PIN when running SecuDE utilities from a script? I am trying to revoke a PEM certificate from a PERL script. That is not easy. I have the command: open (PSEMAINT, 'psemaint -c $USER -i junk1 2>&1 |') ; The environment variable $USER is the name of the ca. An other environ- ment variavble is called $CAPIN which also must be defined in the PERL script. The file called junk1 contain the psemaint commands do be executed. The file looks like this: revoke 1 n R 2 0 0 0 0 0 Revoke is the first command to be executed. 1 stands for certificate number 1, and the n letter stands for no. R = relative date 2 = 2 years 0 = 0 month 0 = day 0 = hours 0 = minutes 0 = seconds This works fine until the program stops and ask me to enter the ca's PIN code. Since this PERL script should revoke the certificates automatically, I must find a way to solve this problem. [Image] There is no SECURE and simple way. The $USERPIN/$CAPIN solution is NOT applicable here!!! [Image] Why can the person who PEM-encrypted a message also be able to decrypt it? One is not supposed to know the recipient's private key. The only key which can decrypt the message must be the recipient's private key. If the person who encrypted the message is able to decrypt the encrypted message, everybody must also be able to do that. [Image] If you create an ENCRYPTED PEM message for n recipients, the SecuDE-PEM utility will generate (n+1) Key-Info header fields per default. One is immediately following the Originator-ID-Asymmetric or Originator-Certificate header field and is the DEK encrypted with the originator's public key. It allows an originator to decrypt his own message (see RFC 1421 4.6.4.2). The other Key-Info header fields are each following the corresponding Recipient-ID-Asymmetric header field and allow the recipients to decrypt the message. You may omit the originator's Key-Info header field through calling pem with the option -n (in case of encryption). [Image] What does a PEM certification request command look like? My idea was that having now generated my PSE, I should send a signed, but not encrypted mail to my intended correspondent in these tests, so that he could obtain my public key from this, and use it to start encrypting messages for me. What is to do? [Image] Create a PEM formatted text through, for example pem mic-clear -i -o -C which transforms the text in in-file to PEM format in out file. Option -C is important in order to have the originator-certificate included in the PEM text. [Image] Is SecuDE-PEM able to read MIME-PEM? The signed test message he sent _me_, intended to pass me _his_ key, contained the following MIME phrase (the indentation is mine), but SecuDE (`pem SCAN') does not seem to understand this at all: ------- =_aaaaaaaaaa0 Content-Type: application/pem-signature Content-ID: <15750.793923674.1@PCCRISC.FDA.GOV> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: PK,MFkwCgYEVQgBAQICAgADSwAwSAJBAMhFRBO7BQxSH6YK+dgC9CTWe8S7= 2qpKwDmZmjof9cqBCXFEprRVEbp1XRydwNhAnYdfrtfaqHLG4po340g1TwkCAwEAAQ=3D=3D MIC-Info: RSA-MD5,RSA,k1OO00thXonN3u+WgYqXsYRKsJW0PlI6UM61Pegehosm/K6PlZuk= faKZ/Tn4InmYsAv7gw6tLJYHthLxYggABg=3D=3D ------- =_aaaaaaaaaa0-- [Image] The text above isn't PEM. It is something which is currently being discussed as a possible privacy enhancement for MIME parts. The most recent version of this is the internet-draft draft-ietf-pem-mime-08.txt which goes under the name MOSS (MIME Object Security Services). I guess your partner is using the software from TIS which obviously implements some older version of this internet-draft. MOSS and PEM (which is RFC 1421 - 1424) have some common ground, but they are addressing different targets. MOSS is for securing MIME body parts, while PEM is for securing entire RFC 822 bodies. SecuDE currently doesn't support MOSS. We will probably have this later. The SecuDE-PEM filter is compliant to RFC 1421 - 1424 and therefore only understands the formats defined there. [Image] Does a MH version exist exploting SecuDE4.4? I wish to use MH with PEM filter. [Image] We have mh-6.8 with integrated SecuDE-PEM (not through the filter, but through integration of the PEM library functions). However, this is based on SecuDE-4.2. The PEM library routine interface changed since then, so some effort is needed to make it compatible with SecuDE-4.4. [Image] How can I create certificates to communicate with RIPEM? [Image] ??? [Image] Why does PEM change CR/LF occurences? [Image] The PEM RFC includes a process of converting CR/LF to a common form to make any PEM letter independant of the destination system. This 'canonification' is not reversible because the original system settings are not transmitted. [Image] Is PEM able to (de-)enhance binary data, e.g. WinWord-Documents? [Image] Not directly. Because of the canonification, 8-bit input could be damaged. Therefore such data must be encoded (using uuencode or SecuDE's encode) to 7-bit-ASCII which can be PEMmed. The UnPEMmed result has to be decoded afterwards. [Image] Are there statically linked binaries of XMst available? [Image] Yes. We are going to provide XMst binaries (via ftp), whereby the latest SecuDE functions will be supported (they may be even more actual than the SecuDE package on ftp!). All SecuDE and X/Motif related stuff is static. We are not allowed to include the ISODE/ICRx libraries for reasons of licensing, so you have to install it locally for X.500/QUIPU access. [Image] How can I generate the xmst.uid module under Solaris 2.4? Is it possible to get an uid binary for Solaris 2.3 or 2.4? I don't have Motif (there is something in Solaris 2.4, but 'uil' programm is missing and make fails)? [Image] Solaris 2.4 provides a Motif-1.2.3 runtime environment (shared libraries), but NOT the development environment (UIL, the Motif user interface language). In our latest release SecuDE-4.4b0, the xmsectool directory contains a compiled UID module. It's generated for Motif-1.2.2 on a SunSPARC 20 with Solaris 2.4, so it should work in your environment (it even should work in any Motif envs <= 1.2.2). The C parts should be compiled by yourself, since there are configurable. (WILL BE CONTINUED...) -------------------------------------------------------------------------- [Image] SecuDE@darmstadt.gmd.de [Image] Security Home Page -------------------------------------------------------------------------- created by Stephan Kolletzki , last modified: Wednesday, 10-May-1995