Subject: Use of private OIDs in WG (standard-track) documents

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Mar 2015 23:50:44 -0500

Hello IETF,

small question: is it allowed to use private OIDs (i.e., subtree of 
1.3.6.1.4.1.XXXX.) in WG documents that are on standard track ? I am 
asking because in the TRANS wg, that is what is happening and I do not 
really feel comfortable adopting OIDs that are under the control of a 
single organization. Would this be a first case ?

Thanks,
Max

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Mar 2015 01:42:48 -0400

On Sat, Mar 28, 2015 at 12:50 AM, Massimiliano Pala <[email-masked]> wrote:
> 1.3.6.1.4.1.XXXX.) in WG documents that are on standard track ? I am asking
> because in the TRANS wg, that is what is happening and I do not really feel
> comfortable adopting OIDs that are under the control of a single
> organization. Would this be a first case ?

Once the OID is assigned, it is out of control of the assigner. So it
is not a problem. We have used RSA labs OIDs from the start.

We have in the past had many discussions on this and various solutions
proposed. One being to set up an OID for a specific project and hand
that over to the IETF together with the spec.

But at the end of the day, renumbering code points in existing specs
only introduces divergence and error. It is to be avoided.

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 28 Mar 2015 08:47:08 -0500

Hi Philip,

were those OIDs that for PKCS from RSA ? Is there any other example of 
this happening
in the last 5/10yrs ? I think that allowing this as a common practice is 
a bit dangerous.
Is this the official position of IETF ?

BTW, I think that once the sub-tree of the OID is assigned to the 
company, that is in
complete control of that company - that is why we have the private OIDs 
in the first
place.

If this is a practice that IETF should discourage, should we have a 
clear policy written
somewhere that we can all adhere to ?

I would like to know the official IETF position on this issue.

Cheers,
Max

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sat, 28 Mar 2015 09:53:54 -0400

Generally speaking, the answer is no.  What you should do is assign an experimental OID until such time as the MIB goes to RFC.

	--Tom

> On Mar 28, 2015:12:50 AM, at 12:50 AM, Massimiliano Pala <[email-masked]> wrote:
> 
> Hello IETF,
> 
> small question: is it allowed to use private OIDs (i.e., subtree of 1.3.6.1.4.1.XXXX.) in WG documents that are on standard track ? I am asking because in the TRANS wg, that is what is happening and I do not really feel comfortable adopting OIDs that are under the control of a single organization. Would this be a first case ?
> 
> Thanks,
> Max
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Mar 2015 14:18:10 +0000

Max,

On 28/03/15 13:47, Massimiliano Pala wrote:
> I think that allowing this as a common practice is a bit dangerous.

What danger do you perceive here? I'm not seeing it. Nor do I see any
need at all for an "official" IETF-wide position, and in fact, such a
position is quite likely to be counterproductive IMO.

And as Phill said, re-numbering, if it breaks code, isn't a good
plan. Asking if it would break code, etc. on the trans list, is a
totally reasonable question btw and that discussion is already
happening there.

S.

PS: This isn't about a MIB, but a PKI thing.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Mar 2015 10:49:29 -0400

> totally reasonable question btw and that discussion is already

I will just add that in the crypto area, the reason I want OIDs is to
remove the IETF from the evaluation process entirely.

Vanity crypto takes IETF time and once an RFC issues it will be used
by marketing to claim 'IETF endorses ROT13 cipher' regardless of the
pledges made when the document was being processed.

The value of OIDs that we cannot duplicate with an IETF scheme is that
they have no connection to IETF and thus no endorsement can be claimed
or implied.

There seems to be a growing consensus in the crypto area for one
mandatory to implement cipher and one backup cipher in case the main
one is broken. I would like to see the use of IETF code points
restricted to such ciphers with an escape hatch for OIDs to serve all
other needs.

Yes, OIDs are obnoxious, but that seems a fitting penalty for vanity crypto, no?

---

From: Leif Johansson <[email-masked]>
Date: Sat, 28 Mar 2015 10:13:19 -0500

> 28 mar 2015 kl. 09:18 skrev Stephen Farrell <[email-masked]>:
> 
> 
> Max,
> 

+1 we have enough work already wo having to invent stuff like this to keep us busy

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 28 Mar 2015 11:04:53 -0500

Hi Stephen, all,

it seems that lately we do not agree on many positions :-(

However, my concern is about a procedure and I do think asking for a
"standardized" approach to how OIDs should be presented in RFCs is not
a bad idea. Why this discussion would be counter productive ?

Anyhow, I did not ask to start a discussion (this could be useful, IMHO),
all I asked is "what is the official position of IETF." - if there is 
none, then
we might talk about starting this discussion.

When I saw the WG document, I was surprised to see the use of OID raw
values directly in the document - there was no mention about the fact that
the selected OID values were under a private subtree (Google), something
that I have never seen before in a WG document in the past 15yrs.

I want to point out that, in this specific case, there was no mention of the
OIDs in the IANA section. My guess is that the authors felt that there 
was no
need to ask IANA to assign an OID since the used value is already in control
under its own private sub-tree. Since this document is in its -06 version, I
guess this was approved by the WG chair(s).

/*If this is a perfectly viable option*/, that it should be made clear.

/*If this is not the desired approach*/, also that should be made clear.

I do not understand why _/*asking for an official position about this 
would*/__/*
*/__/*be an issue*/_ - it is perfectly ok to say "IETF does not care 
about what OIDs
are inside RFCs". I have a preferred approach, but here I am just asking
if we can get an official position about the topic. Are we not allowed 
to ask
for clarifications anymore ?

Therefore,*I do reiterate my request for an official position about this 
issue*.

This is in the interest of having a clear understanding of what the desired
procedure (or what is the current best-practice) is and what principle 
should be
followed within the IETF community.

Coming to my specific concern, I see potential issues in allowing values 
from
different (especially private) sub-trees that are not related to each 
other for
OIDs that clearly belong together (e.g., extensions for PKIX protocols 
and data
structures - OCSP messages and X509 Certificates - should, logically, be 
under
the PKIX OID) might create confusion and it would be quite difficult to 
have a clear
understanding of OIDs used in a particular area - very common 
engineering principle.

This is why, and this is my personal opinion, a coherent approach is, 
IMHO, paramount.

Thanks,
Max

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Mar 2015 21:19:06 +0000

On Fri, Mar 27, 2015 at 11:50:44PM -0500, Massimiliano Pala wrote:

> I do not really feel

I don't see any possibility of "control" of a leaf OID once it is
assigned.  

All that organizations control s the issuing of new OIDS under
particular prefixes, and their prerogative is basically limited to
avoiding collisions with other people assigning OIDs under their
respective prefixes.  Once you publish an OID as fit for a particular
purpose, you cannot take it back.

So I see no risk here.  MIT's and Microsoft's OIDS are used in
Kerberos, for example.  This has not and cannot cause any problems.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Mar 2015 18:08:19 -0400

Victor eve understates the case

Ietf could assign oids in pretty much any space it likes and get away with it. Only recourse would be a lawsuit and heaven help the lawyer trying to draft a claim

All the registries do is to help avoid collisions. These are really just numbers we have a process for avoiding double issue of

Sent from my difference engine

> On Mar 28, 2015, at 17:19, Viktor Dukhovni <[email-masked]> wrote:
>

---

From: Sean Turner <[email-masked]>
Date: Mon, 30 Mar 2015 14:43:40 -0400

> Kerberos, for example.  This has not and cannot cause any problems.

I’m with Victor and don’t see the issue.  We’ve got standards track RFCs with OIDs from NIST, Certicom, RSA, and “infosec” and those are just the ones I can come up with off the top of head.

spt

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 14:29:06 -0500

On Mon, Mar 30, 2015 at 02:43:40PM -0400, Sean Turner wrote:
> I’m with Victor and don’t see the issue.  We’ve got standards track
> RFCs with OIDs from NIST, Certicom, RSA, and “infosec” and those are
> just the ones I can come up with off the top of head.

I agree.

We also have experience with the effects of changing such protocol
constants at publication time:

 - The Kerberos V GSS-API mechanism (RFCs 1964 and 4121).

   Many implementations still embed old OIDs.  I wasn't around then but
   the transition to the new OIDs must have broken acceptor
   implementations.

 - IPsec NAT traversal (which had a constant that changed with each
   version of the I-D).

and probably others.

As a matter of taste it might be better to use IETF OID space, but that
would effectively require having procedures for *early* IANA assignment
of IETF OID arcs to upcoming Internet-Drafts.  As it is I don't think we
have procedures for that, therefore it should be no surprise that we see
non-IETF OID arc assignment in Internet-Drafts and RFCs.  I see this as
a pre-requisite.  Anyone wanting us to use IANA-assigned OID arcs
exclusively.. should submit, and see through to publication, an
Internet-Draft providing for such early assignment.

Nico
--

---

From: Melinda Shore <[email-masked]>
Date: Mon, 30 Mar 2015 11:45:29 -0800

The assertion that this kind of trivia needs to be resolved before
adopting a working group document is a complete non-starter.  That
is just simply incorrect - a matter of personal preference, at
best.

I'd like to propose that the draft authors create a ticket
to the effect that the IANA considerations section needs revision
(which it does, regardless of which arc the OIDs belong to).

Melinda

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Mar 2015 20:49:55 +0100

On 30/03/15 20:29, Nico Williams wrote:
>  that
> have procedures for that,

See RFC7120 and RFC7299 (as Russ pointed out on the trans list).
We have those procedures now.

There is still, however, no real issue to be dealt with here.

S.

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 15:05:53 -0500

> We have those procedures now.

Thanks for the pointers!

> There is still, however, no real issue to be dealt with here.

Agreed.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 31 Mar 2015 09:12:19 -0400

> There is still, however, no real issue to be dealt with here.

Agreed, these are just sequences of octets and at this point, IETF is
one of the very few places still using them. As long as the IETF does
not assign the same OID twice, it really makes no difference.

Renumbering is certainly to be avoided. We have been there with
X-Headers. Requiring renumbering just for the sake of taxonomic order
is silly. Pluto is still a damn planet and that really big dinosaur
with a long neck is still a Brontosaurus no matter what the academics
claim.

We might be making the situation worse however by insisting that IANA
issue OIDs to organizations rather than for projects. This is one of
the few instances where IANA is acting as a non-IETF registry on
behalf of the (now defunct) ITU-T.

If we had a registry for projects, people could take an OID arc for
their project. Use it in private space during development and then
transfer control to the IETF or W3C or OASIS or wherever if the
project turns into a standards track effort.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 31 Mar 2015 11:04:00 +0100

> (which it does, regardless of which arc the OIDs belong to).

Ticket created.

http://trac.tools.ietf.org/wg/trans/trac/ticket/81

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 31 Mar 2015 15:48:23 +0000

> behalf of the (now defunct) ITU-T.

I'm actually using an organizational EKU OID that is not for a "project".
The organizational arc is just fine.

-- 
	Viktor.