Hello,
thanks to Peter’s initiative, Carl and I worked again through the LTANS OID structure and want to use the last opportunity (before ERS is published) to clean a few things up. In the past we added a few OIDs to the LTANS tree which were only referenced in drafts but later removed again. So now is the good time to clean this up.
Based on Peter's proposal but not completely following it, we plan to use the following structure.
At the bottom I give some reasons why Carl and I chose the structure as listed below.
Please take a look at it and post comments or objections to the mailing-list until April-12.
(comment: it’s only the structure of the LTANS OID number tree with no real impact, so a short review time should be sufficient.)
But now to the structure:
Starting with the general prefix:
ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) ltans(11) }
below this level we will have:
ers OBJECT IDENTIFIER ::= { ltans 1 } - Evidence Record Syntax
ltap OBJECT IDENTIFIER ::= { ltans 2 } - Long Term Archive Protocol
And below ers and ltap the different module versions:
module88 OBJECT IDENTIFIER ::= { ers 1 } - Module ASN.1 1988-Syntax
module97 OBJECT IDENTIFIER ::= { ers 2 } - Module ASN.1 1997-Syntax
module88 OBJECT IDENTIFIER ::= { ltap 1 } - Module ASN.1 1988-Syntax
module97 OBJECT IDENTIFIER ::= { ltap 2 } - Module ASN.1 1997-Syntax
And below this, for both ers and ltap each:
(also inspired by your LTAP draft, we will add a version number for the module - just in case we later need to update it - citing the LTAP draft: version numbers of 0 relate to all draft status, version number is 1 with the release of the RFC):
version OBJECT IDENTIFIER ::= { module88 1 } - Version number for this RFC
version OBJECT IDENTIFIER ::= { module97 1 } - Version number for this RFC
Or to be more precise:
For ERS:
version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) module88(1) version(1) } - Version number for ERS RFC
version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) module97(2) version(1) } - Version number for ERS RFC
and for LTAP:
version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) module88(1) version(1) } - Version number for LTAP RFC
version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) module97(2) version(1) } - Version number for LTAP RFC
And at last, the EncryptionMethod oids from the ERS draft:
id-em OBJECT IDENTIFIER ::= { ers 3 } - Encryption Method
or written in the long form:
id-em OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) id-em(3) }
and below that, the two identifiers used in ERS:
id-er-internal OBJECT IDENTIFIER ::= {id-em 1}
id-er-external OBJECT IDENTIFIER ::= {id-em 2}
(this is only _renaming_ the existing identifiers, describing the selection method when using ERS with CMS - this is only replacing the existing identifier _names_ (nothing else!)
Old names were: id-EvidenceRecord-Internal and id-EvidenceRecord-External – new names: id-er-internal and id-er-external
There are several OIDs that have only been used in older and already expired versions of drafts; we will actively state that they be removed from the registry. These are: id-ct, id-em, id-mod-ers, id-evidence-record, id-em-env-data.
Reasons and thoughts about the organization:
1. I strongly prefer to order the tree at the first level semantically (ers/ltap/...) and then by module version (module88/module97/...). In my opinion the semantics is more important than the syntax version (and at a later point in time new syntax might be presented for an existing semantic)
2. By intent, we ordered module88 and module97 with the numbers growing with the ASN.1 syntax numbers, so 1 and 2. (the higher the number the later and more current the version).
With the following reasons: 1) we should list both modules sheer technically and that is as 88 and 97 compliant - there may be other changes to ASN.1 in the future and so there may be other newer modules (maybe “module2010”) in the future. And 2) in case there might be newer module versions (let's say “module2010”) in the future, I'd prefer them to appear in chronological order, so that everyone can deduct that the higher numbered versions are the more recent ones and choose these. (Although I know that this can not be guaranteed) (comment: For this reason we chose module88(1) and module97(2) and not module97(1).)
I hope these reasons are comprehensible. As I said, if you have questions, comments or concerns please send them to the mailing-list (or contact Carl and me directly).
Thanks,
Tobias
Chair of LTANS
__________________________________________
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:tobias.gondrom@xxxxxxxxxxxx
Internet: http://www.opentext.com/
Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton
This email 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 email 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 email are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. The transmission of this email by OTC is not to be construed as a waiver by OTC and/or the individual sending this email on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising.