What is cryptographic sealing? While revising my CAdES library I encountered some "sealing issue" in digital signatures.

The Win SDK signtool.exe has a /seal parameter which produces 1 authenticated attribute in the signature "Intent to Seal" and one unauthenticated attribute "Sealing Signature" in the signed file.

I 've also seen that in PDF files. Couldn't find more online on it.

My questions are:


What is the purpose of "sealing" vs simply signing a message?
What are the OIDs associated with them? What are the relative RFCs?
Is it simply a matter of adding 2 attributes in the PKCS#7 or is there another issue I must take into account?
Is there a difference when timestamping a "sealed" message?
Cryptographic sealing is the application of asymmetric cryptography to encrypt a session key so that it cannot be used-- until it is decided to remove the seal and use the key.  It is a protection mechanism. See this description from Oracle:


  Sealing the symmetric key involves creating a sealed object that uses
  an asymmetric cipher to seal (encrypt) the session key. The RSA
  asymmetric algorithm cannot be used because it has the size
  restrictions described in the next section, and the sealing process
  makes the session key too large to use with the RSA algorithm.


The idea of cryptographic sealing has been around for a long time. A paper from 1981, Cryptographic Sealing for Information Secrecy and Authentication., by David K. Gifford, goes into interesting detail about it:


  A new protection mechanism is described that provides general
  primitives for protection and authentication. The mechanism is based
  on the idea of sealing an object with a key. Sealed objects are
  self-authenticating, and in the absence of an appropriate set of keys,
  only provide information about the size of their contents. New keys
  can be freely created at any time, and keys can also be derived from
  existing keys with operators that include Key-And and Key-Or. This
  flexibility allows the protection mechanism to implement common
  protection mechanisms such as capabilities, access control lists, and
  information flow control. The mechanism is enforced with a synthesis
  of conventional cryptography, public-key cryptography, and a threshold
  scheme.


So, the purpose of sealing is very different from that of signing.  Sealing prevents use of a session key. I have been unable to find any RFCs that deal with sealing.  Nor have I found any applicable OIDs. The timestamping involved in sealing, as far as the encryption process goes, will be the same as normal, as far as I can see. RFC 5652 (Cryptographic Message Syntax) does not specifically mention cryptographic sealing.