RE: [kmip] KMIP Spec References/Acronyms

[Robert Lockhart <Robert.Lockhart@thalesesec.com>]

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 [turners@ieca.com]
Sent: Tuesday, September 29, 2009 9:00 AM
To: kmip@lists.oasis-open.org
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 ussales@thalesesec.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales.