Thanks Ben, I have the basics on private/public key and generating your own key, but I think they are wanting it verified by a CA. I posted the requirements below to make it easier and eliminate the barrier (me) from the actual need..
We used to handle about 300 people worldwide utilizing PGP, missionaries mostly operating in "Secure" areas of the world and that was a royal pain.. Especially when someone didn't post their key to the centralized key ring, etc....Why cant this person get my email? Point finger ---->here.. This just seemed to be a few steps higher up the PKI knowledge tree than I have experience with.. I just need to know which provider can do what is needed... I appreciate any insight into this, as most of the queries are pulling up ssl certs or verisign for pki infrastructure. I think I just need a smartcard with the software or utilize gnu with the cert they provide.... Any pointers.... ------------------------------------------------------------------------------------------------------------------------------------- To start off line signature you have to click on the button Off line signature or Off line validation instead, thus downloading those new or updated data into a single file with name extension .txt (it has a text format) which you save on a directory of your choice or is automatically saved on the desktop. Please do not change the file name, the file content nor the file name extensions automatically assigned. b) Digitally sign the downloaded file with your smart card or security token, by means of the executable file, software tool or utility usually supplied by the same provider, which you have to install on your computer, in case you sign with a smart card, or which may be available on your security token. You start the execution of that software and digitally sign a file in many ways, for instance by choosing an option from the menu you can see after a right click on the file icon or file name. This signature is performed in asynchronous mode, which means: outside from our web application, with no deadline. This signature must be made by a person delegated from his/her company to register its Medical Devices and/or Medical Devices of other delegating companies, by means of our web application. For instance, if you have downloaded a file called DatiAltreAziende210420091820471411.txt after the digital signature its name should have become DatiAltreAziende210420091820471411.p7m or DatiAltreAziende210420091820471411.txt.p7m Besides .p7m another valid file name extension of the signed file could also be .p7s , which differs because in this case the file is not encrypted, while any other file extension of signed files, as for instance .pdf , can't never be signed or accepted by our web application. After this point of the signature process, do not change, by means of our web application, any data you have previously modified and downloaded in the above mentioned .txt file until the following c) step (upload) has been completed: otherwise that following step will not be successful until the previous step (download) has not been repeated before. For a Medical Device, or a System or assembled kit, the data subject to a single signature also include: - the names of the manufacturer, agent or other delegated subject - the EC certificates - the data of any other Medical Device required for its functioning (as registered in our data base) - the data of any other component of the System or assembled kit. c) Then, using again our web application, through its main menu Off line signature and its option: Upload signed files select and upload in our web application the file you have signed at the previous step. Click on the Browse button to perform the search of the directory which contains the signed file to be selected, then click on the Save button. Then in a short while a message will inform you about the final result of your off line signature, confirming if the signature operation has been successful. In case the mandatory first signature described above at point 1) has not been performed before, a warning message is shown. The same happens in case a manufacturer, agent or other delegated subject has been previously selected during the registration of the data of a Medical Device or System or assembled kit now subject to the signature, but the data of the same manufacturer, agent or other delegated subject has been only saved and not also signed after their registration. Off line signature is properly made only after the completion of this third step of its process: in case you sign a file on your computer but later you never upload the corresponding signed file into our web application, the data included in the signed file will not turn out signed. In case you have signed to validate Medical Devices data, you can check their status, which is shown in the corresponding row of any Medical Devices list using our application: it is expected to have become V (validated) and, within the following 24 hours, to automatically become P (published). You can check the result of the signature using the feature described in the following chapter of our web application user manual for foreign manufacturer: 2.4.1.9.1 View the DM validation status . Greg Sweers CEO ACTS360.com P.O. Box 1193 Brandon, FL 33509 813-657-0849 Office 813-758-6850 Cell 813-341-1270 Fax -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Tuesday, October 04, 2011 8:57 PM To: NT System Admin Issues Subject: Re: Needing to encrypt a file On Tue, Oct 4, 2011 at 8:26 PM, Greg Sweers <gswe...@acts360.com> wrote: > Are these programs assuming that I have a certificate already... GPG (GNU Privacy Guard) implements the OpenPGP standard. You can generate your own certificate (keypair) locally. Indeed, in "classic" PGP, this is the way it was usually done. Everyone generated their own keypair, and exchanged public keys. (Maybe you got your public key signed by others, to build a "web of trust", but that's optional.) PKI came later to PGP. Alice generates a keypair -- public and private keys, which go together. Alice sends her public key to Bob. Alice writes a message, signs it with her private key, and mails that to Bob. Bob uses Alice's public key to authenticate the message. Bob takes a file, encrypts it with Alice's public key, and sends it to Alice. Alice uses her private key to decrypt the message. If Bob also sends a public key to Alice, they can do encrypted, authenticated mail. Alice encrypts her message with Bob's public key, and signs it with her private key. Only Bob can read it, and Bob can be sure Alice wrote it. All that said: Encryption can be a very bumpy road. A lot of people expect it to be like a toaster, where you plug it in and it works. Not so. Everyone has to be on the same page -- and the same set of standards and options -- for anything to work. The entity giving you the crypto requirement should really be giving you a detailed, formal spec. I can't count how many times someone at %WORK% has come to me saying %CUSTOMER% wants us to do crypto with them. I start asking the needed questions, and without fail, the customer end goes, "Oh, you mean I don't just have to click a button? Then never mind." -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
