Subject: Re: [abfab] OIDs

From: Sean Turner <[email-masked]>
Date: Tue, 01 Feb 2011 10:44:45 -0500

No word back from IANA yet, but I've pinged them again.  I'm hoping that 
we could get an OIDs here:

http://www.iana.org/assignments/smi-numbers

under this arc:

Prefix: iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5)

Decimal   Name          Description                           References
-------   ----          ------------------------------------  ----------
       0   Reserved                                            [IANA]
       1   SPKM          Simple Public Key Mechanism           [Adams]
       2   SNEGO         Simple GSS-API Negotiation            [Pinkas]
       3   PIM           PEM-Based IDUP Mechanism              [Adams]
       4   MIM           MSP-Based IDUP Mechanism              [Adams]
       5   p7im          PKCS #7-Based IDUP Mechanism          [Adams]
       6   meim          MOSS-Enabling IDUP Mechanism          [Adams]
       7   pkix          Public Key Infrastructure             [Housley]
       8   ipsec         IPsec Key Management                  [Thayer]
       9   lipkey        LIPKEY Mechanism Using SPKM           [RFC2847]
      10   iakerb        IAKERB GSS-API Mechanism              [Trostle]
      11   ltans         Long-Term Archive and Notary Services [Housley]
      12   msec          Multicast Security                    [RFC4534]
      13   gsscma        GSS_C_MA Mechanism Attributes         [RFC5587]
      14   scramsha1     SCRAM-SHA-1                           [RFC5802]

we'd try to get the next # (assuming 15) and then we can manage the arc 
under that.  Sound like a plan?

spt

On 1/26/11 8:46 AM, Sam Hartman wrote:
>>>>>> "Sean" == Sean Turner<[email-masked]>  writes:
>
>      Sean>  Sam,
>
>      Sean>  The question is whether you think we should get a new OID
>      Sean>  every time the syntax changes.  I agree that assigning an OID
>      Sean>  out of an "experimental" and then changing it to an
>      Sean>  "operational" arc if the syntax didn't change is kind of a
>      Sean>  waste of time.  I have this vague notion of the syntax
>      Sean>  changing a lot.  If the WG doesn't think that's going to
>      Sean>  happen then we probably don't have to go the experimental then
>      Sean>  switch to operational route.
>
> I haven't answered this directly because  syntax is a poorly defined
> term here.
> These OIDs do not describe objects encoded using ASN.1.
>
> If we were using ASN.1 I'd say that whenever we changed the syntax since
> the last used version, we should change the OID. By last used version, I
> mean any version that someone claimed to have implemented. If we
> published draft 2 today and found a minor error and fixed it in draft 3
> tomorrow I would not typically require an OID change even if the syntax
> changed.
>
> Here, I think we should change the OID if things change in a manner that
> breaks compatibility.  We have some extension points in the spec so many
> of the things we might want to do would not involve an OID change.  One
> thing we've discussed (support for null GSS target names) probably
> should involve an OID change because it changes the semantics (and
> probably syntax) of the first message from client to server.
>
> I expect we'll have one OID change from the OID in Luke's privaty arc
> we're having today (for the target name change above).  Around that time
> I expect there will be people using the code and past that point I think
> we'd need to be fairly strict about OID changes. I don't see a need for
> any spec changes that would require an OID change beyond that point,
> which realistically means it will probably happen once or twice. (There
> are always changes you don't anticipate.)
>
> --Sam
>