Subject: R: Registering a Certificate Policy OID

From: Santoni Adriano <[email-masked]>
Date: Tue, 6 Mar 2001 18:39:35 +0100

One last remark: do not expect people from national standardization bodies
to know what an OID is :-#

A

-----Messaggio originale-----
Da: Phillip H. Griffin [mailto:[email-masked]]
Inviato: giovedì 1 marzo 2001 0.27
A: David Simonetti
Cc: Cameron Smith; [email-masked]
Oggetto: Re: Registering a Certificate Policy OID

A couple of small points though. 

Semantics seem to matter to humans. I've helped 
set up OID registries for folks who felt that 
where they got their OID arc from had marketing
implications, even though the encoded OID value
is just an opaque string that has no semantics 
at all. 

So XYZ Consortium may wish to purchase an ISO
OID under "iso(1) identified-organization(3)"
or "joint-iso-itu-t(2) internationalRA(23)",
rather than use a free IANA OID, simply 
because they feel that this makes them a
recognized international organization.

Other folks may have OID size requirements that 
preclude using a free IANA OID for some purposes,
due to the length of these values when they are 
encoded. Instead an OID that encodes in less 
octets might be purchased so that object 
identifiers require less space or bandwidth 
in messages.

Phil

David Simonetti wrote:
> 
> Excellent summary, Russ!  I have found IANA to be the most convenient.
> 
> Dave S.
> 
> Russ Housley wrote:
> 
> > Cameron:
> >
> > It is absolutely critical that private OIDs are obtained from legitimate
> > authorities!  There are two basic strategies for obtaining legitimate
> > OIDs.  The first strategy is to register the objects with an
> > authority.  This strategy is very convenient if the PKI uses a small
number
> > of relatively stable OIDs to represent certificate policies.  The second
> > strategy is to obtain an arc from an authority and assign OIDs as
> > needed.  This strategy may be preferred if policies are less stable or
many
> > OIDs are needed.
> >
> > ANSI is the registration authority for the US for organization names
under
> > the global registration process established by ISO and ITU.  A fact
sheet
> > with links to an application form is located at the ANSI web site
> > (http://web.ansi.org/public/services/reg_org.html).  The ANSI OID arc
for
> > organizations is 2.16.840.1.  ANSI charges a fee for OID arc
> > assignments.  It takes approximately two weeks to receive the assigned
OID
> > arc from ANSI.  ANSI will assign a number (NEWNUM), creating a new OID
arc:
> > 2.16.840.1.NEWNUM.
> >
> > In most countries, the national standards association maintains an OID
> > registry.  As with the ANSI arc, these are generally arcs assigned under
> > the OID 2.16.  It may take some investigation to find the OID authority
for
> > a particular country.  The addresses for ISO national member bodies may
be
> > found at http://www.iso.ch/addresse/membodies.html.  The information
> > includes postal address and electronic mail.  In many cases, a web site
is
> > specified as well.
> >
> > Another possible starting point is the International Register of ISO DCC
> > NSAP schemes.  NSAP stands for Network Service Access Point, and is used
in
> > various international standards.  The registry for schemes may be
obtained
> > at http://www.fei.org.uk/fei/dcc-nsap.htm.  The web site currently lists
> > contact information for thirteen naming authorities, some of which will
> > also assign OIDs.
> >
> > The Internet Assigned Numbers Authority (IANA) assigns private
enterprise
> > numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs
to
> > over 7,500 companies to date.  The application page is located at
> > http://www.iana.org/forms.html, under Private Enterprise Numbers.  The
IANA
> > usually takes about one week.  An OID from IANA is free.  IANA will
assign
> > a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM.
> >
> > The U.S. Federal Government maintains the Computer Security Objects
> > Registry (CSOR).  The CSOR is the naming authority for the arc
> > 2.16.840.1.101.3, and is currently registering objects for security
labels,
> > cryptographic algorithms, and certificate policies.  The certificate
policy
> > OIDs are defined in the arc 2.16.840.1.101.3.2.1.  The CSOR provides
policy
> > OIDs to agencies of the U.S. Federal Government.  For more information
> > about the CSOR, see http://csrc.nist.gov/csor/.  For more information on
> > OIDs for certificate policies, see http://csrc.nist.gov/csor/pkireg.htm.
> >
> > Good luck,
> >     Russ
> >
> > At 04:20 PM 2/26/2001 -0800, Cameron Smith wrote:
> > >(Pardon my ignorant question and wide distribution, but I don't know
where
> > >else to turn.)
> > >
> > >How does one obtain/register a Certificate Policy OID for an
organization?
> > >
> > >Regards,
> > >
> > >Cameron
> > >
> > >--
> > >Cameron Smith
> > >PKI Security Analyst
> > >Symantec Corporation
> 
> --
> David Simonetti
> Securify (www.securify.com), 410-356-2260

*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.