Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials
RFC 5588

Note: This ballot was opened for revision 04 and is now closed.

(Tim Polk) Yes

(Jari Arkko) No Objection

Comment (2009-06-04)
No email
send info
I believe these two text excerpts are in contradiction:

   o  default_cred BOOLEAN -- if TRUE make the stored credential
      available as the default credential (for acquisition with
      GSS_C_NO_NAME as the desired name or for use as
      GSS_C_NO_CREDENTIAL)

   ...

   Finally, if the current credential store has no default credential
   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
   if the default_cred input argument is TRUE, and the input credential
   can be successfully stored, then the input credential will be
   available for acquisition with GSS_C_NO_NAME

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2009-06-02)
No email
send info
  In the Gen-ART Review by Elwyn Davies on 23-May-2009, two minor points
  are raised:

  1. The whole sequence of GSS-API standards does not define the type
     names (whether generic e.g., INTEGER or specific e.g., CREDENTIAL
     HANDLE) used in the pseudo-code definitions of the APIs.

  2. It is fairly obvious but it would be worth a phrase indicating that
     the error codes, etc come from RFC 2743 and the C type names come
     from RFC 2744.

(Cullen Jennings) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Alexey Melnikov Recuse