Initializes a new instance of the EnvelopedData class
Initialization parameters
Encrypted content information
Optional
originatorOptionally provides information about the originator. It is present only if required by the key management algorithm. It may contain certificates and CRLs.
Collection of per-recipient information. There MUST be at least one element in the collection.
Optional
unprotectedCollection of attributes that are not encrypted
Version number.
The appropriate value depends on originatorInfo
, RecipientInfo
, and unprotectedAttrs
.
The version MUST be assigned as follows:
IF (originatorInfo is present) AND
((any certificates with a type of other are present) OR
(any crls with a type of other are present))
THEN version is 4
ELSE
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures include pwri) OR
(any RecipientInfo structures include ori)
THEN version is 3
ELSE
IF (originatorInfo is absent) AND
(unprotectedAttrs is absent) AND
(all RecipientInfo structures are version 0)
THEN version is 0
ELSE version is 2
Static
CLASS_Name of the class
Helpers function for filling "RecipientInfo" based on recipient's certificate. Problem with WebCrypto is that for RSA certificates we have only one option - "key transport" and for ECC certificates we also have one option - "key agreement". As soon as Google will implement DH algorithm it would be possible to use "key agreement" also for RSA certificates.
Recipient's certificate
Optional
parameters: {}Additional parameters necessary for "fine tunning" of encryption process
Optional
variant: numberVariant = 1 is for "key transport", variant = 2 is for "key agreement". In fact the "variant" is unnecessary now because Google has no DH algorithm implementation. Thus key encryption scheme would be choosen by certificate type only: "key transport" for RSA and "key agreement" for ECC certificates.
Crypto engine
Add a "RecipientInfo" using a KeyAgreeRecipientInfo of type RecipientKeyIdentifier.
Optional
key: CryptoKeyRecipient's public key
Optional
keyId: ArrayBufferThe id for the recipient's public key
Optional
parameters: anyAdditional parameters for "fine tuning" the encryption process
Crypto engine
Add recipient based on pre-defined data like password or KEK
ArrayBuffer with pre-defined data
Additional parameters necessary for "fine tunning" of encryption process
Optional
hmacOptional
iterationOptional
keyOptional
keyOptional
keyVariant = 1 for pre-defined "key encryption key" (KEK). Variant = 2 for password-based encryption.
Crypto engine
Decrypts existing CMS Enveloped Data content
Index of recipient
Additional parameters
Crypto engine
Creates a new CMS Enveloped Data content with encrypted data
WebCrypto algorithm. For the moment here could be only "AES-CBC" or "AES-GCM" algorithms.
Content to encrypt
Crypto engine
Converts the class to JSON object
JSON object
Static
blockStatic
compareStatic
defaultReturns default values for all class members
Default value
String name for a class member
Static
fromBERCreates PKI object from the raw data
Initialized and filled current class object
ASN.1 encoded raw data
Static
schemaReturns value of pre-defined ASN.1 schema for current class
ASN.1 schema object
Input parameters for the schema
Generated using TypeDoc
Represents the EnvelopedData structure described in RFC5652
Example
The following example demonstrates how to create and encrypt CMS Enveloped Data
Example
The following example demonstrates how to decrypt CMS Enveloped Data