Subject: Re: [cicm] OID for algorithm identifiers?

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 6 Aug 2010 15:22:06 -0400

We need to make a decision about the proposal below.
so I'm putting out to the list for a consensus check.

"Should algorithms be specified using the proposal below?"
(1) Yes / Agree
(2) No / Disagree

(1) means that every place that an algorithm is specified 
(e.g., channel creation) either an OID or a name MUST be
provided using the syntax proposed below.

(2) means that algorithms SHOULD NOT be specified in 
this manner.

Please respond to this email with your choice by 2010-08-13 17:00 EDT (COB next Friday).

Thanks,
Lev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Wednesday, June 16, 2010 10:52 AM
To: CICM Discussion List
Subject: Re: [cicm] OID for algorithm identifiers?

On Thu, 2010-06-10 02:52 Basil Dolmatov wrote:
> Better use OIDs, maybe having some means for creating plain string 
> "aliases" for referring given OIDs

Instead of aliases, I propose the following:

1. Algorithms SHOULD be named using their OID prefixed with "oid:"
2. Where an OID is unavailable, algorithms SHOULD be named with "name:" 
	followed by a human-readable algorithm name and mode separated with dashes.
	(This is the current method of naming algorithms in Section 4.1.3)

EXAMPLE:
SHA-256:
	"oid:2.16.840.1.101.3.4.2.1" (preferred)
OR	"name:SHA-256" (acceptable)

Regardless of which method is used, the exact strings available for use
MUST be documented in the Implementation Conformance Statement (ICS).

How does that sound?

Lev
_______________________________________________
cicm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cicm

---

From: "Bourget, Dennis" <[email-masked]>
Date: Fri, 6 Aug 2010 13:42:54 -0700

(1) Yes / Agree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Friday, August 06, 2010 12:22 PM
To: CICM Discussion List
Subject: Re: [cicm] OID for algorithm identifiers?

Please respond to this email with your choice by 2010-08-13 17:00 EDT
(COB next Friday).

Thanks,
Lev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Wednesday, June 16, 2010 10:52 AM
To: CICM Discussion List
Subject: Re: [cicm] OID for algorithm identifiers?

1. Algorithms SHOULD be named using their OID prefixed with "oid:"
2. Where an OID is unavailable, algorithms SHOULD be named with "name:" 
	followed by a human-readable algorithm name and mode separated
with dashes.
	(This is the current method of naming algorithms in Section
4.1.3)

EXAMPLE:
SHA-256:

How does that sound?

Lev

---

From: Tony <[email-masked]>
Date: Sat, 07 Aug 2010 07:54:00 -0400

Lev
On this issue, I vote no.
This is far to implementation specific.

Thank You
Tony Martin

---

From: "Kevin W. Wall" <[email-masked]>
Date: Sat, 07 Aug 2010 11:09:17 -0400

> "Should algorithms be specified using the proposal below?"

Yes. Of course IETF will properly register the OIDs, right?

-kevin
-- 
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

---

From: [email-masked]
Date: Mon, 9 Aug 2010 17:43:58 -0400

I vote (1).

Jim Howard
Director and Chief Engineer - Information Assurance
L-3 Communications, Communication Systems - East
Phone: 856-338-3504
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Friday, August 06, 2010 3:22 PM
To: CICM Discussion List
Subject: Re: [cicm] OID for algorithm identifiers?

Thanks,
Lev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Wednesday, June 16, 2010 10:52 AM
To: CICM Discussion List
Subject: Re: [cicm] OID for algorithm identifiers?

EXAMPLE:
SHA-256:

How does that sound?

Lev

---

From: "Novikov, Lev" <[email-masked]>
Date: Tue, 10 Aug 2010 13:31:29 -0400

Kevin,

> Of course IETF will properly register the OIDs, right?

Not quite. First, for those who may not know, OIDs are like a 
distributed set of registries. So, for example, the OID
1.3.6.1.4.1 represents iso.org.dod.internet.private.enterprise
which is administered by IANA (sister org to IETF) and
is the root for a majority of the world's OIDs.

However, all OIDs beneath 1.3.6.1.4.1 are administrated by the
organization that is assigned that branch in the tree. So,
for example, 1.3.6.1.4.1.7128 is assigned to Worcester Polytechnic 
Institute. WPI gets to choose how to manage the OID space for 
1.3.6.1.4.1.7128.* (i.e. all sub-branches).

Every organization that already has an IANA-registered space
(see: http://www.iana.org/assignments/enterprise-numbers and 
http://www.alvestrand.no/objectid/1.3.6.1.4.1.html for a partial list)
can administrate their own OID space, and they need not be public in 
any way-- not in the IETF or elsewhere.

Of course, the current proposal allows someone to avoid using OIDs
altogether and use the "name:" prefix to supply their own name,
but we want to encourage the use of OIDs to avoid name conflicts.

Lev

---

From: "Novikov, Lev" <[email-masked]>
Date: Tue, 10 Aug 2010 15:42:17 -0400

Tony,

> This is far to implementation specific.

Just to clarify: the existing algorithm naming-convention
was just a convention to help implementers construct
a somewhat unique name for each algorithm-mode pair.

The current proposal basically says: if the algorithm
you want to use has been assigned an OID, try to use that OID
(prefixed with "oid:") instead of the naming convention. 
Otherwise, use the string as per the previous convention,
but prefix it with "name:".

* Which aspect of the proposal do you consider too implementation-specific?
* Would you like to propose an alternative way to specify the algorithm?

(FYI: You don't have to have an alternative to point out the flaws
in this one; I just want to know what you consider the flaw.)

Thanks,
Lev

---

From: "Kevin W. Wall" <[email-masked]>
Date: Tue, 10 Aug 2010 21:40:28 -0400

I knew that. I used to contract with Chemical Abstract Service who had
defined some their own OIDs for use with ASN.1 and BER encoding using the
snacc compiler. I worked on a project that used OIDs for that, some of
which were exclusive to CAS. (I think it was for some proprietary
extensions to Z.3950 protocol IIRC, but that's been 10+ years ago and
my mind has undergone considerable bit rot since then and the required
error correction exceeds the Hamming distance available to my gray
matter. :)

Anyhow, I probably should have phrased the question better. I meant, these OIDs
*are* going to be registered by IETF under their namespace so that future RFCs
don't use the same OIDs for something different.  Even though they don't need
to be "public", you do need to ensure that they are unique, otherwise semantic
chaos could result.

Of course, on the downside, I looked at the IANA enterprise registry (the
first URL you provided) and did not find IETF nor the
"Internet Engineering Task Force" listed there.

Just that someone somewhere needs to keep track of them so they don't
get reused for something else that has a different purpose.

-kevin

---

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 11 Aug 2010 15:49:35 -0400

Kevin,

> to be "public", you do need to ensure that they are unique, otherwise semantic

The OIDs will be registered, but it is unlikely it will be through the IETF.
In general, algorithms will be registered with the national or private body
that standardizes or maintains that algorithm. 

For example, the SHA-256 hashing algorithm was published by NIST in FIPS-180-3. 
That algorithm was registered by NIST (within their part of the OID tree) 
as 2.16.840.1.101.3.4.2.1
(see: http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html
for other NIST algorithms)

I imagine that non-public algorithms will be maintained in registries managed
by the relevant national body. For example, national Canadian algorithms 
are likely to be maintained by the Canadian Department of National Defence 
and registered within their own OID space (1.3.6.1.4.1.1380). Similarly, 
Swedish algorithms might be registered by the Swedish Defence Research Agency
and reside in their OID space (1.3.6.1.4.1.23588). The same principle
applies to proprietary vendor algorithms.

But none of this activity involves the IETF. The uniqueness of the
OIDs stems from the autonomy delegated to the children of each node.
Each organization must ensure that there are no conflicts within their OID
space.

As an aside, organizations that do not already have access to OID space can
get a free node in the tree through IANA--one of the "Enterprise Numbers":
(see: http://pen.iana.org/pen/PenApplication.page)

> "Internet Engineering Task Force" listed there.

The IETF does not need an "Enterprise Number" because it "controls" the OID
1.3.6.1 (internet). IANA's Enterprise Number registry is a descendant 
(1.3.6.1.4.1). 

Just to clarify, IANA's job is to maintain registries of unique names and numbers
for the IETF (see: http://www.iana.org/protocols/).

Lev

---

From: "Kevin W. Wall" <[email-masked]>
Date: Wed, 11 Aug 2010 23:26:34 -0400

Lev,

Thanks for taking time to clarify that.
-kevin
-- 
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME