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<turn...@ieca.com> 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
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
