Subject: LTANS-ERS-10: example for CryptoInfos and encryptionInfo
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Date: Fri, 22 Dec 2006 00:28:59 +0100
List-Id: <ietf-ltans.imc.org>

Hello,

as the optional fields CryptoInfos and EncryptionInfo in the
EvidenceRecord structure in the draft are currently simply placeholders
that can flexibly be filled as needed, I wanted to outline the use a bit
more to give you the opportunity to object if s.th. is unclear or going
the wrong way. In the standard application most probably both fields are
not necessary - but may be required in certain situations.
(small personal comment: up to today I did never use or need the fields
as I did neither need to provide additional information in the
CryptoInfos nor had the problem to store additional information with
encrypted content, so those two fields have only been discussed in
theoretical technical discussions of certain combinations/contexts which
most probably require this additional information but never happened to
me. But if s.o. else already implemented one of those classes I would be
happy to read about it on the mailing-list.)  
We should also consider that we should provide at least one example of
the two fields in the Appendix of ERS:

Just for historic information: until including ERS version-08 we used
the following syntax for both structures:
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo

   CryptoInfo ::= SEQUENCE
   {
      cryptoInfoType    OBJECT IDENTIFIER
      cryptoInfoValue   ANY DEFINED BY cryptoInfoType
   }

   EncryptionInfo ::= SEQUENCE
   {
      encryptionInfoType OBJECT IDENTIFIER,
      encryptionInfoValue [0] EXPLICIT ANY DEFINED BY encryptionInfoType
   }

With version-09 we changed them to a more modern ASN.1 struct:
CRYPT-INFO-CLASS ::= TYPE-IDENTIFIER

   CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF
         INSTANCE OF CRYPT-INFO-CLASS

cryptoInfos allows the storage of data useful in the validation of
   the archiveTimeStampSequence. This could include possible 
   Trust Anchors, certificates, revocation information or the current
   definition of the suitability of cryptographic algorithms, past and
   present (e.g. RSA 768bit valid until 1998, RSA 1024bit valid until 
   2008, SHA1 valid until 2010). These items may be added based on the
   policy used. Since this data is not protected within any timestamp,
   the data should be verifiable through other mechanisms. Such
verification
   is out-of-scope of this document.

And similar:
ENCRYPTION-INFO-CLASS ::= TYPE-IDENTIFIER

   EncryptionInfos ::= SEQUENCE SIZE (1..MAX) OF
         INSTANCE OF ENCRYPTION-INFO-CLASS

  encryptionInfos contains a set of instances of ENCRYPTION-INFO-CLASS
objects 
   that contain various pieces of information necessary for the
unambiguous 
   re-encryption of unencrypted content so that it exactly matches with
the 
   encrypted data objects protected by the EvidenceRecord.

An example for the CryptoInfo would be e.g. objects that contain a used
algorithm identifiers and the date until it has been considered secure:
e.g. 

CRYPTO-INFO-CLASS: 
AlgTimeFrame::= SEQUENCE
   {
      usedAlgorithm 	AlgorithmIdentifier,
	validFrom		GeneralizedTime,
	validUntil		GeneralizedTime,
   }

With GeneralizedTime from RFC2459 as also used in RFC3161.

An example instance of a ENCRYPTION-INFO-CLASS:
E.g. the content protected by the ERS is encrypted with a usual
combination of asymm. and symm. encryption of RSA-1024 combined
with.AES-256. (RSA-1024 to encrypt the key and the IV for the AES-256
encryption.)
In this case an instance (and probably the only one) of the class would
be:
ENCRYPTION-INFO-CLASS:
UsedEncryptionAlgorithmsAndParameters::= SEQUENCE 
{
	usedAlgorithm 	AlgorithmIdentifier
}

>From looking at the structures it seems even easier to understand if you
use the normal structures we had in version-08 but I hope this correctly
matches with the new structure in version-09/version-10.

Please provide your opinion/feedback on this implementations
example/detail. 

Thank you very much, Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked] 
Internet: http://www.opentext.com/  

This e-mail is protected by domestic and international copyright laws
and treaties and is the property of Open Text Corporation, it may
contain confidential and/or trade secret information of the Open Text
Corporation and/or its subsidiaries (OTC), and may be subject to legal
privilege in favor of OTC. This e-mail may only be lawfully received,
accessed, displayed on a computer screen, printed, copied, and/or used
by the specific addressee(s) named above ("Authorized Recipient") for
the purpose for which it was sent by OTC. All other rights and licenses
to this e-mail are fully reserved to OTC. If you are not an Authorized
Recipient, you are required to immediately delete this e-mail in its
entirety without printing, copying, using, and/or re-transmitting this
e-mail, either in whole or in part. The transmission of this e-mail by
OTC is not to be construed as a waiver by OTC and/or the individual
sending this e-mail on behalf of OTC of any of their respective rights
or privileges at law or otherwise, howsoever arising.