Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)

From: [email-masked]
Date: Tue, 10 Jul 2001 15:16:38 +0000

Two points - the first is the pushback on the 
work "methods". I believe that the term "features" is 
better here, and to the second question... if the 
methods are private why is there any need to register 
them. The only need I can see in issuing a publicly 
available OID is if there are publicly linked 
participants of unknow origins and as such would need 
some way of registering these "OID's" locally.

T.
--
Regards,
Todd
> 
> "4.2  Certificate Extensions
> 
>    The extensions defined for X.509 v3 certificates provide methods for
>    associating additional attributes with users or public keys and for
>    managing the certification hierarchy.  The X.509 v3 certificate
>    format also allows communities to define private extensions to carry
>    information unique to those communities."
> 
> Then there is a section Private Internet Extesions where two specific
> extension are specified.  I assume that this is the same as the private
> extensions mentioned above.
> 
> Question: How are arbitrary private extensions supposed to be added?
> You must register/define an OID?
> 
> Regards
> Anders R
> 
> 
>

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 13:37:43 -0400

Todd:

The point is that a unique OID must be used.  Registration is the process 
used to obtain the unique OID, even if the resulting OID is not published 
in any public manner.

Russ

---

From: [email-masked]
Date: Tue, 10 Jul 2001 23:29:28 +0000

Russ I am aware of OID registration, I have several PEN 
OIDs myself. 

The point is that if 

1)  this is an OID that is only used within a closed 
environment there is no need to keep anyone else from 
using it. 

2)  If you are referring to a process for propagating an 
OID so that both users could have the same definition on 
the OID they are using, then that is a good idea but 
that is not per se "registration".

So I disagree with your commentary and pushback. What I 
feel you are referring to is an arbitrary need 
to "register all OIDs" as in with the IANA rather than a 
method of OID content negotiation and IMHO I will 
continue to disagree with your commentary.

--
Regards,
Todd
> 
> Todd:
> 
> The point is that a unique OID must be used.  

Not true. If I have an OID and it is a private 
system I can do whatever I want with that OID. 
I do not need IANA or anyone else besides my 
private use partners to tell me what the OID means.

> Registration is the process

---

From: [email-masked]
Date: Wed, 11 Jul 2001 14:19:31 +0000

--
Regards,
Todd
> No.

Yes! 

> 
> The process of obtaining an OID must ensure that the same OID is not used 
> for two different extensions.  If this where to happen, then a replying 
> party could not know which syntax or semantics to apply to the extension in 
> a particular certificate.

And this could easily be done by an agreement by two individuals or the code 
they are running at either end of the transaction. Or more importantly
by the apps being run at both ends.

> 
> I never said that the registration process had to lead to publication of 
> the OID, the associated syntax, or the associated semantics.  I did say, 
> and remain adamant, that OID use collisions must be avoided.

No again - what needs to happen is that the App must be coded to deal with
OID collisions not the protocol. 
But that's the whole point. The registration process is 
only necessary if the Use Model requires an external 
"lookup step"... What if the OID itself carries
privacy protected information? As a CERT extension 
this is actually a real potential and mandating that it be
a public process has some strange implications for limiting 
the scope of "Son Of..."

Look - If the app that is using the cert has 
the OID constructs it uses hard coded into it then... no public registration
is needed.

> 
> Russ
> 
> At 11:29 PM 7/10/2001 +0000, [email-masked] wrote:

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 11 Jul 2001 10:27:20 -0400

Todd:

We agree that no PUBLIC registration is needed.  However, the coding that 
you suggest to handle OID collisions is likely to be error prone.

You say that you have several PEN arcs.  If you assign an OID from one of 
those, it will be unique (unless you are sloppy and use the same one for 
more than one purpose).  You do not have to tell anyone that you made the 
assignment, the associated syntax, or the associated semantics.  Just use 
it in your application.  As long as the extension is marked non-critical, 
it will be ignored by everyone else.  If the extension is marked critical, 
everyone else will reject the certificate -- maybe that is what you want.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 11 Jul 2001 09:11:03 -0400

Todd:

No.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 16 Jul 2001 14:59:27 -0400

Todd:

In my mind, such a protocol, if needed at all, would not be part of the 
certificate and CRL profile.

Russ

At 10:28 PM 7/12/2001 +0000, [email-masked] wrote:

>Graham -
>To the last comment you made - We need to build "the OID
>discovery and authentication protocol".
>
>This will allow policy and policy-centric events to be
>included dynamically and authenticated inline. This in my
>mind is a key missing piece of Son Of...
>
>T.
>
>--
>Regards,
>Todd
> >
> > Todd,
> >
> > Yes I agree in a totally closed environment, between mutually agreeing
> > parties there is no need to register OIDs.  But why avoid the registration,
> > it only has to be done once to establish an arc, it does not need doing for
> > each OID which is allocated in a closed environment.
> >
> > I cannot see how an application can be coded to handle OID collisions for a
> > lower cost than the effort involved in the registration.
> >
> > Lastly how does an application handle two extensions in a certificate with
> > the same identifier (OID) but having separate meanings when there is no way
> > of telling them apart.
> >
> > Graham Bland
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: 11 July 2001 15:20
> > > To: Housley, Russ
> > > Cc: [email-masked]
> > > Subject: Re: New draft of son-of-2459 (Was: I-D
> > > ACTION:draft-ietf-pkix-new-part1-08.txt)
> > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Todd
> > > > Todd:
> > > >
> > > > No.
> > >
> > > Yes!
> > >
> > > >
> > _______________________________________________________________________
> >
> > This message is confidential and is intended for the addressee only;
> > unless clearly stated that this disclaimer should not apply, this
> > e-mail is not intended to create legally binding commitments on
> > behalf of any company in the British Interactive Broadcasting
> > Holdings Limited group,  nor do its contents reflect the corporate
> > views or policies of any such company. Any unauthorised disclosure,
> > use or dissemination, either whole or partial, is prohibited. If you
> > are not the intended recipient of the message, please notify the
> > sender immediately.
> > _______________________________________________________________________