PKI

(Public Key Infrastructure)

“Curso de Introducción a la Criptografía” by Jordi Íñigo Griera is licensed under a
Creative Commons Attribution 4.0 International License.
Project hosted at github.com/jig/crypto

Confianza

los datos se protegen con CIPHER_HASH

$\downarrow$

derivadas con KEA

$\downarrow$

autenticados (los secretos) con SIGN

$\downarrow$

Claves públicas de servidor y cliente (opcionalmente)
?

Confianza: Claves públicas

hemos cambiado el problema de

“compartir claves simétricas”

por el de

“compartir claves públicas (asimétricas)”

hemos simplificado el problema, pero sigue siendo demasiado complejo como para que lo solventen los usuarios

¿cómo intercambiamos las claves públicas (PBK) de forma segura?

Confianza: Claves públicas

nos hace falta un mapeo seguro:

PBK_interlocutor $\rightarrow$ identidad interlocutor

los datos se protegen con CIPHER_HASH

$\downarrow$

derivadas con KEA

$\downarrow$

autenticados (los secretos) con SIGN

$\downarrow$

Claves públicas de servidor y cliente (opcionalmente)

$\downarrow$

identidad interlocutor

Confianza: Claves públicas

PBK_interlocutor $\leftrightarrow$ identidad interlocutor

sistema central de distribución: lista de PBKs compartida
- idea original de Diffie y Hellman el 1976
manualmente: nos guardamos una lista de PBKs propia
- SSH
certificados
- PGP: gestión descentralizada (Web of trust)
- PKI/X.509: gestión centralitzada

gestión "manual": SSH

el cliente guarda cifrada la clave privada
el cliente se guarda en un directorio las claves públicas de los servidores en los que confía
el servidor guarda en claro la clave privada (del servicio sshd)
el servidor guarda la clave pública válida per a cada usuario

Gestión con Certificados

un certificado contiene la tupla:

(identidad interlocutor, PBK_interlocutor)

y para poder verificar la integridad (y la autenticidad) una tercera parte de confianza (TTP) firma esta tupla:

PVK_TTP(identidad interlocutor, PBK_interlocutor)

Nota: PVK_TTP(…) significa firma RSA o ECDSA sobre la cadena "…"

Tercera parte de confianza

hemos de confiar en PBK_TTP

el propietario de la PVK_TTP correspondiente puede ser:

una autoridad central: en una Infraestructura de Clave Pública (PKI)
un "igual": en el modelo "web of trust" (como en PGP)

Nota:
PGP: Pretty Good Privacy
PKI: Public Key Infrastructure

Encadenado

frecuentemente ni en PGP ni en PKI dispondremos localmente de la PBK_TTP que ha firmado el certificado de nuestro interlocutor

pero podemos "llegar" de forma segura si descargamos los certificados de los eslabones intermedios

PVK_i-1(i, PBK_i) PVK_i-2(i-1, PBK_i-1) $\vdots$ PVK_TTP(1, PBK₁)

PGP

en PGP podemos firmar las claves de conocidos nosotros mismos si nos las han pasado de forma segura

...y ellos también pueden hacer lo mismo, permitiendo alzacanzar un paso más

Nota: PGP tiene una versión de libre distribución llamada GPG derivada de la rfc4880 (OpenPGP)

PGP

con PGP podemos llegar a tener confianza en grupos pequeños o medianos, pero no escala bien en grupos grandes

cada eslabón (certificado) tiene una garantía de autenticidad $<1$

a partir de unos cuantos certificados el nivel de seguredad deja de ser aceptable

PKI: Infraestructura de clave pública

el encadenado de certificados lo hacemos hasta un punto común

en el caso extremo, todo el mundo puede recibir un certificado de una única TTP: una autoridad de certificación (CA)

CA única

si recibimos una conexión TLS, o recibimos un mensaje de correo firmado, o queremos enviar uno cifrado, sólo nos hace falta recibir el certificado del interlocutor:

PVK_CA(identidad_interlocutor, PBK_interlocutor)

este certificado, que lo podremos encontrar en un repositorio cualquiera, y lo podremos validar a condición de que conozcamos previamente la clave PBK_CA
(obtenida por medios alternativos fiables)

la PBK_CA es el único elemento que hace falta distribuir de forma segura, el resto los podremos obtener de forma no segura y validarlos

CA única: limitaciones del modelo

simple para los clientes, pero frágil:

si la CA queda comprometida, todo el sistema falla
todos los usuarios deben estar de acuerdo en unas mismas prestaciones de seguridad (y el mismo coste)

CAs múltiples

los usuarios deben conocer de antemano una lista de PBK_{CA_i}
- son las CAs raíz (root CA)

los usuarios pueden recibir certificados no de las CAs que conocen los usuarios finales, si no de entidades intermedias
- son las CAs subordinadas

CAs raíz

las diferentes CAs pueden especializarse: niveles de seguridad, métodos de registro, legislación, costes, o simplemente diferentes organizaciones

los usarios pueden escoger en qué CAs raíz confiar y en cuales no

el usuario (…) debe gestionar
la lista de CAs (raíz) de confianza

CAs subordinadas

las CAs subordinadas emiten certificados a los usuarios

$\Downarrow$

están en línea o como mínimo, están activas frecuentemente

$\Downarrow$

probabilidad "alta" de compromiso de la PVK

$\Downarrow$

hemos de poderlas revocar en caso de compromiso de la PVK

Jerarquia de CAs: Patrón habitual

CA raíz: sólo emite certificados para CA subordinadas y "revocaciones"
- está activa en momentos puntuales (off-line)
- en caso de compromiso no hay protocolo definido
CA subordinada: emite certificados finalistas (usuarios, servidores)
- está en línea constantemente, ya sea por red pública o privada
- en caso de compromiso se sigue el procedimiento de revocación de CA

Jerarquía de CAs: Patrón habitual (ii)

CA raíz: los usuarios (e.g. clientes y servidores TLS) tienen instaladas las CA raíz en que confían
CA subordinada: la reciben de su interlocutor

e.g. cuando en una conexión TLS el servidor nos presenta su PBK, nos la aporta certificada por una CA subordinada, juntamente con el certificado de la CA subordinada que la ha firmado:
PVK_CAsub(id-servidor, PBK_servidor)
+ PVK_CAroot(id-CAsub, PBK_CAsub)

la PBK_CAroot la debemos tener previamente instalada

RA: Autoridad de Registro

el procedimiento de registro gestiona la validación de credenciales (registro) que demuestra que un titular posee la clave privada correspondiente a la clave pública que presenta

la validación de posesión de la PVK ha de ser automática:
- petición de certificación PKCS #10
- certificado autofirmado X.509
la validación de la identidad del titular puede ser:
- presencial: para certificados personales, o con políticas de certificación restrictivas como los certificados EVC
- en línea, basados en desafíos sobre el control de:
  - una cuenta de correo
  - un nombre de dominio DNS
  - un servicio web

Certificados X.509

(previa)

Base64, DER, ASN.1

Certificados X.509

Estructura serializada PVK_CA(interlocutor, PBK_interlocutor)

estructura ASN.1 denominada Certificate (también X.509)
serialización DER
conversión a carácteres Base64 (opcional)
encapsulado PEM (opcional)

Ejemplo Certificado Root

(ejemplo de certificado de google.com)

Formato PEM

PEM: Privace Enhanced Mail

principio/final comenzando por guiones y indicando el contenido
(opcional) cabecera detallando el contenido
contenido en base64 (segmentado en líneas cortas)

Codificación Base64

Convertimos cada 3 bytes en 4 carácteres:

26 letras mayúsculas
26 letras minúsculas
10 cifras
+ y /

total: 64 carácteres

y si la cadena no es múltiple de 3 bytes, añadimos = al final:

sin = indica que el último bloque tiene todos tres bytes significativos
= indica que el último bloque tiene dos bytes significativos
== indica que el último bloque tiene un byte significativo

ASN.1: Serialización DER

DER: Distinguished Encoding Rules

funcionalmente equivalente a XML, JSON o la serialización nativa de Java $\rightarrow$ tipo lógico convertido a secuencia de bits

DER es independiente de la arquitectura del procesador
(endianness, tamaño de los registros de la CPU)

Codificación TLV: Tipo + Longitud + Valor

ASN.1: Serialización DER

Tipo + Longitud + Valor

TL + V: Valor no estructurado o final (cadena, entero…)
TL + (TL+…, TL+…, …): valor estructurado (SEQUENCE…)

Experimento: Parser DER en línea: lapo.it

ASN.1: Notación para definir tipos

ASN.1: Abstract Syntax Notation (One)

equivalente a los "esquemas" XML, a las "clases" de Java (que después podemos serializar), etc.

ASN.1

Tipos básicos

Numéricos: INTEGER, BOOLEAN, ENUMERATED…
Cadenas: OCTET STRING, BIT STRING, Utf8String, GeneralizedTime…
NULL
OBJECT IDENTIFIER…

ASN.1: OBJECT IDENTIFIER

secuencia única que identifica un concepto, que se obtiene
de la ITU-T/CCITT o la ISO

e.g. AESAlgorithmIdentifier ::= 2.16.840.1.101.3.4.0.1

{ joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) modules (0) aes (1) }

ASN.1: Tipos Constructores y Metatipos

SEQUENCE: equivalente a un struct de C/C++
SEQUENCE OF: equivalente a un vector [] de C/C++
SET: como SEQUENCE pero sin orden (semántica)
SET OF: como SEQUENCE OF pero sin orden (semántica)
CHOICE: alternativa de tipo; equivalente a union de C/C++

ASN.1: Certificados X.509 (rfc5280)

ejemplo de estructura ASN.1:

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

Certificados X.509

Certificate

`PVK_CA(interlocutor_x, PBK_{interlocutor_x})`

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

`Name`

el Name define los Distinguished Name o DN

un DN es una secuencia de RDN (Relative DN)

RDNs habituales:

CN: Common Name (Nombre del usuari o DNS del servidor)
OU: Organisational Unit (Departamento)
O: Organisation (Empresa)
C: Country (Estado)
otros: (L) localidad, (ST) estado/provincia, (DC) domain component…

corresponden a un estructura en árbol (LDAP, X.500)

Otros campos

validity {notBefore, notAfter}
issuer Name
serialNumber INTEGER
extensions SEQUENCE OF {OID, Bool, OCTET STRING}

`extensions SEQUENCE OF {OID, Bool, OCTET STRING}`

es una manera de añadir información adicional que no está especificada en el momento de definición de la estructura X.509
(X.509 versión 3)

hay extensiones que hace falta que sean procesadas:
se marcan con Critical True: si un sistema procesa el certificado y no entiende la extensión (no conoce el OID) debe dar el certificado por inválido

BasicConstraints (2.5.29.19): cA, pathLenConstraint
KeyUsage (2.5.29.15)
NameConstraints (2.5.29.30)
AuthorityInformationAccess (1.3.6.1.5.5.7.1.1)
…

Lista de CAs reconocidas

las CAs reconocidas (raíz) deben obtenerse de forma fiable

dentro del S.O. y las actualizaciones del S.O.
dentro del software que utiliza las claves (navegador, validador de firmas) y sus actualizaciones

el S.O. o el software actúan de "TTP raíz"

en algunos sistemas se pueden modificar estas listas (por parte del usuario, o el administrador de sistemas)

Certificados “verdes”

¿Hay CAs raíz buenas? ¿cómo gestiono la lista de CAs raíz que usaré?

Si el certificado del servidor HTTPS al que nos conectamos está bajo una de estas CA raíz: se muestra en verde

El hecho que la lista de certificados pueda ser manipulada (usuario, sysadmin) ha hecho que aparezcan mecanismos "más seguros"

Por ejemplo: los navegadores han separado en dos listas las CA root confiables: una modificable por el usuario/administrador y otra no (CABforum)

verdes y verdes

Certificados EV, Extended Validation: las CAs que emiten estos certificados siguen unos procedimientos específicos para la validación de los datos del titular (registro); la lista de certificados raíz normalmente está grabada en el código fuente de los navegadores, etc. Los certificados EV exigen que el propietario del dominio siga procedimientos que se auditan (presencialmente)

Los certificados no-EV no tienen porqué pasar ninguna auditoria, habitualmente se valida simplemente la posesión del servidor Web (HTTP challenge) o del DNS (DNS Challenge)

Ejemplo EV: GitHub.com
Ejemplo no-EV: Google.com

Contramedidas adicionales: Certificate Transparency

las CA bajo Certificate Transparency publican los certificados que emiten en una base de datos distribuida

los propietarios legítimos puede consultar (monitorizar) si alguna otra CA ha certificado nuestro dominio

en realidad, cualquier usuario puede escribir y leer esta BB.DD. distribuida

Ver: SSLmate Cert Spotter

Contramedidas adicionales: DNS CAA

DNS CA Authorization (DNS CAA): la CA comprueba que el DNS (CAA record) le autoriza a emitir certificados para el dominio

Esto obliga a un atacante a tener que comprometer no sólo el servidor
(en caso de usar desafío sobre el control del servidor)
si no el control de titularidad del dominio

CA no fiables

Digisign Server ID – (Enrich) (Malasia, subordinada de Entrust.net Certification Authority (2048)): erróneamente emitió certificados con claves de titular de 512 bit. Se revocó la CA.
DigiNotar (Holanda, varias CA raíz): fueron hackeadas y se emitieron certificados fraudulentos
MCS Holding (test): la CA no estaba conectada (directamente?) a un HSM. Se emitieron certificados de forma fraudulenta para *.google.com entre otros
MD5 Collisions Inc.: una prueba de concepto que se "coló" en Firefox y Chromre al menos
UserTrust "UTN-USERFirst-Hardware" (Comodo): compromiso de una RA (de un usuario+contraseña) que permitió emitir 9 certificados fraudulentos HTTPS
Symantec: miles de certificados emitidos sin una correcta validación del titular^*
…

Revocaciones

Revocación

los certificados tienen una validez limitada en el tiempo, pero es posible que su contenido deje de ser válido antes

si esto pasa, hace falta comunicarlo a la RA (Autoridad de Registro) siguiendo los procedimientos que dictamine la Política de Certificación (o la Declaración de Prácticas de Certificación derivada)

ejemplo DNIe: Declaración de prácticas y políticas de certificación

Razones de revocación

keyCompromise: quizás he perdido el control de mi PVK
affiliationChanged: el DN/SubjectAltName ya no es correcto
superseded: se ha emitido un certificado que lo sustituye
cessationOfOperation: ya no hace falta (e.g. el servidor web ya no existe)
certificateHold: suspendido (posteriormente se cancela la suspensión, o se revoca)
privilegeWithdrawn: algún atributo ya no le corresponde al titular

¿Cómo sabemos si un certificado ha sido revocado?

se publica una CRL
se publica en un servidor OCSP

CRL

Certificate Revocation List

es una lista firmada (rfc5280) que contiene los certicados no caducados que han sido revocados por una CA (o varies: CRL indirectas), el momento en el que han dejado de ser válidos, y la razón por la que han dejado de ser válidos

CRL: observaciones

las CRL pueden crecer mucho: hace falta ajustar el período de validez de los certificados emitidos
se pueden emitir CRL incrementales (delta CRL)
se poden acumular las revocaciones de diferents CA en una CRL (CRL indirectas)

ASN.1: CertificateList (rfc5280)

CertificateList  ::=  SEQUENCE  {
    tbsCertList          TBSCertList,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

TBSCertList  ::=  SEQUENCE  {
    version                 Version OPTIONAL,
                                 -- if present, MUST be v2
    signature               AlgorithmIdentifier,
    issuer                  Name,
    thisUpdate              Time,
    nextUpdate              Time OPTIONAL,
    revokedCertificates     SEQUENCE OF SEQUENCE  {
         userCertificate         CertificateSerialNumber,
         revocationDate          Time,
         crlEntryExtensions      Extensions OPTIONAL -- if present, version MUST be v2
    }  OPTIONAL,
    crlExtensions           [0]  EXPLICIT Extensions OPTIONAL -- if present, version MUST be v2
}

Extensiones

el mismo formato que los certificados, pero otros OID

reasonCode
invalidityDate

OCSP: On-line Certificate Status Protocol

en CAs de gran volumen las CRL son inaceptablemente grandes: OCSP

los servidores OCSP o VA (Validation Authorities) responden el estado de validez de un certificado individual

en servidores web de alto rendimiento,
la VA puede sufrir una carga similar $\rightarrow$ OCSP stapling

Miscelánea

Coste

gestión de la seguridad de las claves de las entidades finales (usuarios):
procedimientos de registro, revocación y renovación, personalización Smart Cards, administración de las CA, CRLA, VA, RA…
renovación de claves de la CA (subordinadas, raíces): las migraciones de PKI hasta ahora han sido masivas por el paso de SHA-1 a SHA-2
compromiso de clave: hay cierta probabilidad (póliza de seguro) de que no se hayan aplicado los procedimientos y medidas técnicas para proteger las claves
certificados “verdes” (contraejemplo: CA Let's Encrypt de la fundación ISRG)
Administración de sistemas: distribución de CA propias de forma segura
Procedimiento de registro para certificación, revocación
complejidad: no/formación…

Time-Stamp Protocol (rfc3161)

las TSA (Time-Stamp Authorities) emiten pruebas firmadas de que un conjunto de bytes (hash) ha sido presentado a una hora determinada

es un formato de petición y uno de respuesta que contiene un token TimeStampToken (TST):
el token TST se puede presentar como prueba de que un documento existia en un cierto momento

TSA: Time-Stamp Authority

las TSA se parecen a las CA pero a parte de disponer de HSM, tienen una fuente fiable de tiempo:
reloj atómico, o un reloj estabilizado térmicamente, o conexión GPS, o connexión a un servidor NTP (Stratum-2 o similar), o alguna combinación de las anteriores (habitualmente las CA utilizan exclusivamente NTP)

Uso

TLS: autenticación de los extremos de la conexión (e.g. HTTPS)
PKCS #7/CMS: cifrado y sobretodo firma

PKCS #7 / CMS

CMS o Cryptographic Message Standard nos permite cifrar o firmar un conjunto de bytes: correo, ficheros individuales, etc.

es una estructura ASN.1:

ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER

PKCS #7 `content`

tipos disponibles:

Data: datos sin tratar
SignedData: datos firmados por uno o más firmantes
EnvelopedData: datos cifrados simétricamente, y claves cifradas con la PBK de uno o más receptores
DigestedData: hash (almacenamiento local, o para posterior ensobrado)
EncryptedData: cifrado en crudo (almacenamiento local, cifrado simétrico)
AuthenticatedData: MAC (almacenamiento local, o en combinación con ensobrado)

que se pueden combinar recursivamente: e.g.
SignedData(Data("datos"), [firmas])

PKCS #7: `content`$\rightarrow$`SignedData`

firma asimétrica

SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,          -- datos firmados
    certificates [0] IMPLICIT CertificateSet OPTIONAL, -- certificados necesarios (CAs sub.)
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,  -- CRL necesarias
    signerInfos SignerInfos }                          -- firma(/as en paralelo)

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo

PKCS #7: `content`$\rightarrow$`EnvelopedData`

cifrado, simétrico o asimétrico (ensobrado)

EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,               -- claves simétricas firmadas al receptor(es)
    encryptedContentInfo EncryptedContentInfo,   -- datos cifrados con clave simétrica anterior
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL
}

PKCS #7: `content`$\rightarrow$`EnvelopedData + SignedData`

una combinación habitual (e.g. S/MIME) es firmar y cifrar

PKCS #7: como archivo de certificados

el PKCS #7 se usa a veces como formato para entregar certificados (y CRL)
(e.g. mi certificado y la cadena de CA):

el PKCS #7 contiene (content) SignedData… conteniendo los certificados y/o las CRL, pero sin datos ni firmas

Otros "formatos PKCS"

PKCS #7: formato ASN.1 firma, cifrado, archivo de certificados y CRL
PKCS #11: plantilla C para librerías (pkcs11.h) de HSM
PKCS #1: (sólo RSA) formatos de firma y cifrado; algunas veces se usa como a manera de identificar el formato de clave privada RSA en claro; usado por servidores (TLS)
PKCS #5: procedimiento para cifrar bytes a partir de una contraseña
PKCS #8: formato de clave privada, habitualmente cifrado con
el procedimiento PKCS #5
PKCS #10: formato de petición de certificación, que contiene los datos de identificación (DN), la clave pública, y la firma para poder validar la posesión (alternativo a un X.509 autofirmado)
PKCS #12: fichero cifrado de clave y certificados (usado por navegadores)

PKI

Confianza

Confianza: Claves públicas

Confianza: Claves públicas

Confianza: Claves públicas

gestión "manual": SSH

Gestión con Certificados

Tercera parte de confianza

Encadenado

PGP

PGP

PKI: Infraestructura de clave pública

CA única

CA única: limitaciones del modelo

CAs múltiples

CAs raíz

CAs subordinadas

Jerarquia de CAs: Patrón habitual

Jerarquía de CAs: Patrón habitual (ii)

RA: Autoridad de Registro

Certificados X.509

Certificados X.509

Ejemplo Certificado Root

Formato PEM

Codificación Base64

ASN.1: Serialización DER

ASN.1: Serialización DER

ASN.1: Notación para definir tipos

ASN.1

ASN.1: OBJECT IDENTIFIER

ASN.1: Tipos Constructores y Metatipos

ASN.1: Certificados X.509 (rfc5280)

Certificados X.509

PVKCA(interlocutorx, PBKinterlocutorx)

Name

Otros campos

extensionsSEQUENCE OF {OID, Bool, OCTET STRING}

Lista de CAs reconocidas

Certificados “verdes”

verdes y verdes

Contramedidas adicionales: Certificate Transparency

Contramedidas adicionales: DNS CAA

CA no fiables

Revocaciones

Revocación

Razones de revocación

¿Cómo sabemos si un certificado ha sido revocado?

CRL

CRL: observaciones

ASN.1: CertificateList (rfc5280)

Extensiones

OCSP: On-line Certificate Status Protocol

Miscelánea

Coste

Time-Stamp Protocol (rfc3161)

TSA: Time-Stamp Authority

Uso

Uso

PKCS #7 / CMS

PKCS #7 content

PKCS #7: content$\rightarrow$SignedData

PKCS #7: content$\rightarrow$EnvelopedData

PKCS #7: content$\rightarrow$EnvelopedData + SignedData

PKCS #7: como archivo de certificados

Otros "formatos PKCS"

`PVK_CA(interlocutor_x, PBK_{interlocutor_x})`

`Name`

`extensions SEQUENCE OF {OID, Bool, OCTET STRING}`

PKCS #7 `content`

PKCS #7: `content`$\rightarrow$`SignedData`

PKCS #7: `content`$\rightarrow$`EnvelopedData`

PKCS #7: `content`$\rightarrow$`EnvelopedData + SignedData`