*********************************************************
TODO
*********************************************************

SPKM GSSAPI v2 calls yet to be done
-----------------------------------
Credential management calls
    all of them
Context-level calls
    all but init_sec and accept_sec
Per-Message calls
    gss_wrap,unwrap
Support calls	
    all of them

mike;
target - accept, acquire_cred, import_name

MECHGLUE 
--------
update to GSSAPI version 2

LIPKEY
------
  - use the DH shared key established by the working code.
  - same issues as with SPKM - which GSSAPIv2 calls does 
    LIPKEY require...

Key Est Alg
-----------
Support PK mutual authentication key-est alg's
that require a user X.509 cert are of great interest to the
Grid community. 

  - SPKM-1, SPKM-2: need to understand RSAEncryption and id-rsa-key-transport
    key algorithms
  - Globus GSSAPI-SSL implementation
	    - add to userlevel rpcsec-gss, should just plug in ;o 
      - create kernel get_mic, verify_mic, wrap, unwrap tokens

*********************************************************
Issues:
*********************************************************

ASN1 encoding of Integers stored as BIT STRINGS
-----------------------------------------------
following Openssl convention, the current spkm implementation
first DER encodes the Integer, and then DER encodes the result
as a BIT STRING.  is this correct?

ANSWER: It was agreed upon at the October 2003 Bake-athon that
these values should be simply encoded in BIT STRING w/o first
encoding as an integer.  This brings up the problem of unknown
lengths, since the OpenSSL routines strip off trailing zeros
of BIT STRINGS.  We'll assume 8-byte length for Random numbers.

Which GSSAPI calls does NFSv4 need
----------------------------------
in the above yet to be done list, which calls do we need. 
do we code calls we don't need?

ANSWER: People are looking for a general solution.  We need
to support all the required GSSAPI calls.

X509 Certificate Management
-----------------------------
1) translating or verifying service@target.host.name into an X.509 Certificate
subject name for an administrative realm

2) initiator (nfs client) acquiring the target X.509 Certificate

	- for DH keyalg, need method of constructing target X.509 name
	- for RSAEncryption, need method of acquiring target X.509 Certificate

Idea: store server (target) X.609 Certificate in known location
( pseudofs root/.X509Cert ). initiator (client) can then read X.509 Certificate
and perform some verification prior to use.

Context Cache
-------------
spkm3 context is stored in the context cache managed by
functions in the lib/gssapi/generic directory

Credential Cache, name cache
--------------------------------------------------
krb5 gss stores credentials and names in a cache, the same cache as contexts,
managed by functions in lib/gssapi/generic.
spkm has yet to use the cred or name cache

krb5_acquire_cred runs on the target.
  - validate input desired name
    i.e. check for name in name cache.
	- verify mechanism
  - create gss cred structure (krb5 specific)

	- call acquire_accept_cred
                 - read in keytab file
                 - figure out which principal to use. desired_name (input) 
                   is used else default name.
                 - keytab entries are searched for principal 
                 - if found, replay cache for the principal is opened (???????)
  - or call acquire_init_cred
  - intern cred handle (save it in cache )

For SPKM - what do we need?


===============================================================================
NEW ISSUES
===============================================================================
02/19/2004 - 
1) All implementors need to agree on the length of the random numbers.
   Eight bytes is what IBM was assuming, we're using 8-bytes with
   padding if necessary (due to truncation of trailing zeros by the
   OpenSSL ASN.1 encoding routines).

2) String format of X.509 names needs to be agreed upon?  IBM assumes
   RFC2253-style names.  Globus assumes older OpenSSL-style names :-/

   [ 5 ] rock/.../spkm% openssl x509 -noout -subject -in spkm.cert 
   subject= /C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=CITI Production KCA/CN=nfs/rock.citi.umich.edu/emailAddress=nfs/rock.citi.umich.edu@CITI.UMICH.EDU
   [ 6 ] rock/.../spkm% openssl x509 -noout -subject -nameopt esc_2253 -in spkm.cert
   subject= 
   [ 7 ] rock/.../spkm% openssl x509 -noout -subject -nameopt RFC2253 -in spkm.cert
   subject= emailAddress=nfs/rock.citi.umich.edu@CITI.UMICH.EDU,CN=nfs/rock.citi.umich.edu,OU=CITI Production KCA,O=University of Michigan,L=Ann Arbor,ST=Michigan,C=US
   [ 8 ] rock/.../spkm% 

   See http://www.mail-archive.com/openssl-dev@openssl.org/msg16651.html for
   a (very) short discussion about this.  Need to write a parsing routine.

3) 
