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

From: "Bland, Graham" <[email-masked]>
Date: Wed, 11 Jul 2001 08:52:19 +0100

Todd,

Surely the registration here for private use need only extend down to the
private arc of the controlling organisation.  If corporation X has an arc
registered then it can maintain uniqueness within this arc without
registering each full OID separately.

If it is making a unique OID public then it should be registered as part of
the publication process. If it is for private use then registration is not
needed, just an agreement between the parties within the private
implementations.

Graham Bland

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 10 July 2001 16:17
> To: Anders Rundgren
> Cc: [email-masked]; Tim Polk
> Subject: Re: New draft of son-of-2459 (Was: I-D
> ACTION:draft-ietf-pkix-new-part1-08.txt)
> 
> 
> 
> 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
> > 
> > 
> > 
> 
_______________________________________________________________________

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.
_______________________________________________________________________

---

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

Graham - the issue is that in some application contexts 
that OID values can and will be hard coded into the 
applications that use them.

For that reason alone it is not smart to constrain the 
protocol use to mandate it. Rather it should be left 
optional and a method of OID corruption or collision 
detection be added if you are so inclined. Otherwise 
there is a mandated need to go to the TTP (the ARC) to 
get the OID identified and that - err well.

The point is that this again is an instance where the 
application that uses the process should be making these 
decisions. Or is it that it is PKIX's opinion that app 
developers are incompetent to do so and must be 
protected from this potential?

--
Regards,
Todd

---

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

By the way - I do agree that in the instances where 
local registration, is required that you are dead on in 
that it likely need only extend down to the org's ARC.

--
Regards,
Todd