RE: Same ECC Algorithm Represented by Multiple KMIP Enumerations

Hi Judy,

>I believe we should edit the enumerations so each algorithm has only one enumeration.

I agree.

>We can update the table in the UG to show the mapping of the enumeration to each of its names.

>What do others in the TC think? Should we make this change to the Spec and UG or should

>we leave things as specified in the Additional ECC Algorithm proposal?

I think we should make the changes.

Peter

------------------------------------------------
Peter Robinson - peter.robinson@rsa.com
Senior Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 11, Central Plaza One, 345 Queen Street, Brisbane, Queensland 4000, AUSTRALIA.
Phone: +61 7 3032 5253, Mobile: +61 407 962 150.

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Furlong, Judith
Sent: Friday, 12 July 2013 6:00 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Same ECC Algorithm Represented by Multiple KMIP Enumerations

I wanted to raise an issue to the list that has resulted from adding the Additional ECC Algorithms into the KMIP 1.2 specification – see section 9.1.3.2.5. The ECC algorithms are specified in multiple source documents and in several instances the same algorithm is known by multiple names since it is defined in multiple sources. When the ECC algorithm proposal was prepared for KMIP 1.2 a separate enumeration was given to each ‘named’ algorithm. So this means we now have the same algorithm with multiple enumerations. These duplications are highlighted in the table below (which is presently in section 3.42 of the KMIP 1.2 Usage Guide).

Algorithm Name	KMIP Enumeration Value	OID	Algorithm Synonym(s)
NIST P-192	0x00000001	1.2.840.10045.3.1.1	secp192r1 ansix9p192v1
NIST K-163	0x00000002	1.3.132.0.1	sect163k1
NIST B-163	0x00000003	1.3.132.0.15	sect163r2
NIST P-224	0x00000004	1.3.132.0.33	secp224r1
NIST K-233	0x00000005	1.3.132.0.26	sect233k1
NIST B-233	0x00000006	1.3.132.0.27	sect233r1
NIST P-256	0x00000007	1.2.840.10045.3.1.7	secp256k1 ansix9p256v1
NIST K-283	0x00000008	1.3.132.0.16	sect283k1
NIST B-283	0x00000009	1.3.132.0.17	sect283r1
NIST P-384	0x0000000A	1.3.132.0.34	secp384r1
NIST K-409	0x0000000B	1.3.132.0.36	sect409k1
NIST B-409	0x0000000C	1.3.132.0.37	sect409r1
NIST P-521	0x0000000D	1.3.132.0.35	secp521r1
NIST K-571	0x0000000E	1.3.132.0.38	sect571k1
NIST B-571	0x0000000F	1.3.132.0.39	sect571r1
secp112r1	0x00000010	1.3.132.0.6
secp112r2	0x00000011	1.3.132.0.7
secp128r1	0x00000012	1.3.132.0.28
secp128r2	0x00000013	1.3.132.0.29
secp160k1	0x00000014	1.3.132.0.9
secp160r1	0x00000015	1.3.132.0.8
secp160r2	0x00000016	1.3.132.0.30
secp192k1	0x00000017	1.3.132.0.31
secp192r1	0x00000018	1.2.840.10045.3.1.1	NIST P-192 ansix9p192v1
secp224k1	0x00000019	1.3.132.0.32
secp224r1	0x0000001A	1.3.132.0.33	NIST P-224
secp256k1	0x0000001B	1.3.132.0.10
secp256r1	0x0000001C	1.2.840.10045.3.1.7	NIST P-256 ansix9p256v1
secp384r1	0x0000001D	1.3.132.0.34	NIST P-384
secp521r1	0x0000001E	1.3.132.0.35	NIST P-521
sect113r1	0x0000001F	1.3.132.0.4
sect113r2	0x00000020	1.3.132.0.5
sect131r1	0x00000021	1.3.132.0.22
sect131r2	0x00000022	1.3.132.0.23
sect163k1	0x00000023	1.3.132.0.1	NIST K-163
sect163r1	0x00000024	1.3.132.0.2
sect163r2	0x00000025	1.3.132.0.15	NIST B-163
sect193r1	0x00000026	1.3.132.0.24
sect193r2	0x00000027	1.3.132.0.25
sect233k1	0x00000028	1.3.132.0.26	NIST K-233
sect233r1	0x00000029	1.3.132.0.27	NIST B-233
sect239k1	0x0000002A	1.3.132.0.3
sect283k1	0x0000002B	1.3.132.0.16	NIST K-283
sect283r1	0x0000002C	1.3.132.0.17	NIST B-283
sect409k1	0x0000002D	1.3.132.0.36	NIST K-409
sect409r1	0x0000002E	1.3.132.0.37	NIST B-409
sect571k1	0x0000002F	1.3.132.0.38	NIST K-571
sect571r1	0x00000030	1.3.132.0.39	NIST B-571
ansix9p192v1	0x00000031	1.2.840.10045.3.1.1	NIST P-192 secp192r1
ansix9p192v2	0x00000032	1.2.840.10045.3.1.2
ansix9p192v3	0x00000033	1.2.840.10045.3.1.3
ansix9p239v1	0x00000034	1.2.840.10045.3.1.4
ansix9p239v2	0x00000035	1.2.840.10045.3.1.5
ansix9p239v3	0x00000036	1.2.840.10045.3.1.6
ansix9p256v1	0x00000037	1.2.840.10045.3.1.7	NIST P-256 secp256r1
ansix9c2pnb163v1	0x00000038	1.2.840.10045.3.0.1
ansix9c2pnb163v2	0x00000039	1.2.840.10045.3.0.2
ansix9c2pnb163v3	0x0000003A	1.2.840.10045.3.0.3
ansix9c2pnb176v1	0x0000003B	1.2.840.10045.3.0.4
ansix9c2tnb191v1	0x0000003C	1.2.840.10045.3.0.5
ansix9c2tnb191v2	0x0000003D	1.2.840.10045.3.0.6
ansix9c2tnb191v3	0x0000003E	1.2.840.10045.3.0.7
ansix9c2pnb208w1	0x0000003F	1.2.840.10045.3.0.10
ansix9c2tnb239v1	0x00000040	1.2.840.10045.3.0.11
ansix9c2tnb239v2	0x00000041	1.2.840.10045.3.0.12
ansix9c2tnb239v3	0x00000042	1.2.840.10045.3.0.13
ansix9c2pnb272w1	0x00000043	1.2.840.10045.3.0.16
ansix9c2pnb304w1	0x00000044	1.2.840.10045.3.0.17
ansix9c2tnb359v1	0x00000045	1.2.840.10045.3.0.18
ansix9c2pnb368w1	0x00000046	1.2.840.10045.3.0.19
ansix9c2tnb431r1	0x00000047	1.2.840.10045.3.0.20
Brainpool_P160r1	0x00000048	1.3.36.3.3.2.8.1.1.1
Brainpool_P160t1	0x00000049	1.3.36.3.3.2.8.1.1.2
Brainpool_P192r1	0x0000004A	1.3.36.3.3.2.8.1.1.3
Brainpool_P192t1	0x0000004B	1.3.36.3.3.2.8.1.1.4
Brainpool_P224r1	0x0000004C	1.3.36.3.3.2.8.1.1.5
Brainpool_P224t1	0x0000004D	1.3.36.3.3.2.8.1.1.6
Brainpool_P256r1	0x0000004E	1.3.36.3.3.2.8.1.1.7
Brainpool_P256t1	0x0000004F	1.3.36.3.3.2.8.1.1.8
Brainpool_P320r1	0x00000050	1.3.36.3.3.2.8.1.1.9
Brainpool_P320t1	0x00000051	1.3.36.3.3.2.8.1.1.10
Brainpool_P384r1	0x00000052	1.3.36.3.3.2.8.1.1.11
Brainpool_P384t1	0x00000053	1.3.36.3.3.2.8.1.1.12
Brainpool_P512r1	0x00000054	1.3.36.3.3.2.8.1.1.13
Brainpool_P512t1	0x00000055	1.3.36.3.3.2.8.1.1.14

I don’t believe it is good practice to represent the same algorithm with multiple enumerations and I believe we should edit the enumerations so each algorithm has only one enumeration. We can update the table in the UG to show the mapping of the enumeration to each of its names.

What do others in the TC think? Should we make this change to the Spec and UG or should we leave things as specified in the Additional ECC Algorithm proposal?

Judy

kmip message