167818 - RFE: Implement proposed AES key wrapping mechanism

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P2)

Description

[Terry Hayes]

Comment 1

[Terry Hayes]

NIST is developing a key wrapping method that uses AES to "wrap" other secret 
data.  The wrapped data can be other AES keys or any other secret value, such 
as a random number seed, triple-DES key, private key or password.

A proposed definition of the AES key wrap algorithm is found at:
  http://csrc.nist.gov/encryption/kms/key-wrap.pdf

In addition, an edited version of this document has been submitted as an 
Internet draft to IETF:
  http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-keywrap-00.txt

The IETF draft gives proposed OIDs for this algorithm (one for each key size):

       aes  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) 
          us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 
    
       id-aes128-wrap  OBJECT IDENTIFIER  ::=  { aes 5 } 
       id-aes192-wrap  OBJECT IDENTIFIER  ::=  { aes 25 } 
       id-aes256-wrap  OBJECT IDENTIFIER  ::=  { aes 45 } 
    

Comment 2

[Wan-Teh Chang]

Assigned the bug to Nelson.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

The Internet Draft above has now become an RFC.

See ftp://ftp.rfc-editor.org/in-notes/rfc3394.txt

Comment 4

[Wan-Teh Chang]

Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

status:

The AES Key wrap algorithm was checked into freebl.  It was tested against
the test vectors in the RFC, and passes.  These test cases have not yet been
added to blapitest.

Two new AES Key wrap mechanisms were added to softoken, using CKM_NETSCAPE
mechanism numbers until a real proposal for those mechanisms is written for
and accepted by the PKCS 11 working group.  The code to implement these
mechanisms (on top of freebl) is insufficiently tested.

3 new OIDs and their mappings to the new mechanisms were added to the table
of known secoids.  

No additional work has been done to get any higher layer code (such as 
libSMIME) to use these new mechanisms.  At the moment, I'm not ever sure 
what interface one uses to perform a key wrap based on an OID.  

This work is now pre-empted by another urgent project.  I expect NSS 3.8
will ship with this implementation in essentially this state.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Terry, what is the proposed use for this algorithm?  
Is this to be used in SMIME (CMS)?  or XML encryption? or ??

The mechanism is now implemented in softoken.  
The secoid table now maps the OIDs to the PKCS 11 mechanisms.  

In the absense of a clear definition of where this is going to be used, 
I'm not sure what else to do with this.  

So, I'm taking the unusual step of marking this RFE fixed, so that the
implementation of these 2 new mechanisms will show up as having been done
in NSS 3.8 in bugzilla.  Perhaps another RFE should be filed requesting 
additional enhancement to NSS to use these mechanisms, once that work is
well defined.