Diferencia entre revisiones de «S/MIME»
Contenido eliminado Contenido añadido
Remoción de texto comentado y corrección de la palabra "certificante" (que no existe) por "certificadora" |
m Bot: Arreglando espacios en los enlaces |
||
Línea 19:
Before S/MIME can be utilized in any of the above applications, one must obtain and install an individual key/certificate either from one's in-house [[certificate authority]] (CA) or from a public CA such as one of those listed below. Best practice is to use separate private keys (and associated certificates) for Signature and for Encryption, as this permits escrow of the encryption key without compromise to the non-repudiation property of the signature key. Encryption requires having the destination party's certificate on store (which is typically automatic upon receiving a message from the party with a valid signing certificate). While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, in practice, the S/MIME clients will require you install your own certificate before they allow encrypting to others.
A typical basic personal certificate verifies the owner's identity ''only'' in terms of binding them to an email address and does not verify the person's name or business. The latter, if needed (e.g. for signing contracts), can be obtained through CAs that offer further verification (digital notary) services or managed PKI service. For more detail on authentication, see [[
Depending on the policy of the CA, your certificate and all its contents may be posted publicly for reference and verification. This makes your name and email address available for all to see and possibly search for. Other CAs only post serial numbers and revocation status, which does not include any of the personal information. The latter, at a minimum, is mandatory to uphold the integrity of the public key infrastructure.
| |||