RE: [kmip] KMIP Spec References/Acronyms

I would want to verify which terms are used in which document and place them in the appropriate sections based on their applicability
(Terminology, Normative References and Non-normative References)
of the given document (Specification, Usage Guide, etc...).

 

I am still working on a list of terms that I feel need defining and after I complete that I will check on the terms and references below to see if they are in the current versions.  This will probably be another week
 before I have an initial stab at it completed.

 

Additional comments on the information below are:

I am not sure about the use of draft documents (e.g. FIPS 140-3) as references and we need to be careful what we include as they will most likely change by the time we publish a final set of documents.  This may need some additional
 discussion.

For SHA, instead of FIPS 140-3, I think FIPS 180-3 Secure Hash Standard is more appropriate as the reference.

If we refer to PKCS (maybe as a profile) I believe it should be a single reference and refer back to the PKCS homepage (http://www.rsa.com/rsalabs/node.asp?id=2124)
 where each of the individual specifications are found.

Sean,

 

Thanks for saving me some work of having to look some of these up!

 

Bob L.

 

Robert A. (Bob) Lockhart

Senior Solutions Architect

THALES Information Systems Security

From: Sean Turner []

Sent: Tuesday, September 29, 2009 9:00 AM

To: 

Subject: [kmip] KMIP Spec References/Acronyms

Robert,

Here are some comments on the references/acronyms.

For acronyms (App D):

The ones in parentheses I'll leave to the editor (e.g., SP 800-67 refers 

to ANSI X9.57 for 3DES).  Also, I wasn't sure if I should include the 

version #s in the PKCS#* references.

3DES - Three key Data Encryption Standard specified in

                                           (SP 800-67 or ANSI X9.57)

ASN.1 - Abstract Syntax Notation One specified in ITU-T X.680-X.683

CRL - Certificate Revocation List specified in RFC 5280*

CRMF - Certificate Request Message Format as specified in RFC 4211

DER - Distinguished Encoding Rules specified in X.690*

DH - Diffie-Hellman specified in ANSI X9.42*

ECDH - Elliptic Curve Diffie-Hellman specified in

                                           (SP 800-57 or ANSI X9.63)*

ECMQV - Elliptic Curve Menezes Qu Vanstone specified in

                                           (SP 800-57 or ANSI X9.63)*

HMAC - Keyed-Hash Message Authentication Code**

HMAC-MD - HMAC with MD5 specified in RFC 2104

HMAC-SHA*** - HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 

specified in FIPS 198, RFC 2104, and RFC 4868

MD2 - Message Digest 2 Algorithm specified in RFC 1319

MD4 - Message Digest 4 Algorithm specified in RFC 1320

MD5 - Message Digest 5 Algorithm specified in RFC 1321

PBKDF2 - Password-Based Key Derivation Function 2 specified in RFC 2898

PEM - Privacy Enhanced Mail specified in RFC 1421

PKCS#1 - RSA Cryptography Specifications Version 2.1 specified in RFC 3447

PKCS#5 - Password-Based Cryptography Specification Version 2 specified 

in 2898

PKCS#8 - Private-Key Information Syntax Specification Version 1.2 

specified in RFC 5208

PKCS#10 - Certification Request Syntax Specification Version 1.7 

specified in RFC 2986

PGP - Pretty Good Privacy specified in (RFC 1991 or RFC 2440?)

SHA** - Secure Hash Algorithm as specified in FIPS 140-3

UTF-8*** - Universal Transformation Format 8-bit specified in RFC 3629

X.509 - Public Key Certificate specified in RFC 5280

(don't include the * in the above list)

* added specified in ....

** change from pointing to FIPS 198 (doesn't include HMAC-MD5)

*** removed the 1 (if we don't then should include them all 224, 256, etc.)

**** change from UTF to UTF-8

Should we add acronyms for all of algorithm modes (9.1.3.2.13), padding 

methods (9.1.3.2.14), and role type enumerations (9.1.3.2.16)?

While S/MIME is near and dear to my heart, it can be removed from the 

spec because it is not used.

For references:

Here are some suggested references that we need to add because they 

either refer to an algorithm or are from the references.  I'll leave it 

to the editor to decide whether they are normative or not ;)

NIST FIPS: 140-3 (SHA)

            186-3 (DSA/ECDSA)

            197 (AES)

            198 (HMAC)

NIST SP: NIST SP 800-38 A (for 3DES/AES ECB, CBC, CFB, OFB, CTR

                                            from Sec 9.1.3.2.13)

          NIST SP 800-38 B (for 3DES/AES CMAC from Sec 9.1.3.2.13)

          NIST SP 800-38 C (for CCM from Sec 9.1.3.2.13)

          NIST SP 800-38 D (for GCM from Sec 9.1.3.2.13)

          NIST SP 800-38 E (for XTS from Sec 9.1.3.2.13 BUT it's draft)

ANSI: X9.24 (role type??)

       X9.26 (pad)

       X9.31 (pad)

       X9.42 (DH)

       X9.57 (3DES)

       X9.62 (ECDSA)

       X9.63 (ECDH/ECMQV)

       X9.102 (for X9.102 *?? from Sec 9.1.3.2.13)

       ANSI X9 TR-31 (role types???)

RFCs: 1319 (MD2)

       1320 (MD4)

       1321 (MD5)

       1421 (PEM)

       2104 (for HMAC-SHA1 and HMAC-MD5)

       2898 (for PBKDF2 and PKCS#5 padding)

       3394 (for NISTKeyWrap from Sec 9.1.3.2.13)

       3447 (for pads OAEP, PSS, PCKS#1v1.5)

       3629 (UTF8 - I'm not an expert on character sets so I'm not really

             sure where to point)

       4211 (CRMF)

       4868 (for HMAC-SHA256->512)

       5280 (X.509/certificate)

       5649 (for AESKeyWrapPadding from Sec 9.1.3.2.13)

ISO: 10126 (for a padding method)

      16609 (role types???)

      9797-1 (role types???)

Not sure where to point for PCBC (used in Kerberos v4 but it isn't 

published), CBC-MAC, or SSL3 pad.

spt

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorized. If you are not an addressee or
 the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorized use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from
 your system, please also inform us immediately on +1 (781) 994 4000 or email . Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales.