Mass Update

Thanks for your efforts on this submission.  This
will be published as GFD-054.

Other than updating the header with this GFD #,
the only change I made was to add "Version 2" to the
title in the document - I presume this is the intent,
and acceptable.

Thanks again!

Here's a new version of the document addressing the helpful comments received in the public comment period.  I made the following changes:

- Added a paragraph on pipelining in section 3
- Replaced ASCII with UTF-8 to allow internationalization
- Added a paragraph to the security considerations section and also
   in the 'Put' section about client authorization
- Specified that certificates and certificate requests are DER-encoded
- Specified the byte encoding the number of certificates is 
   unsigned binary with maximum 255

I believe the document is now ready for final editor review.

Author: Please review public comments here:
  https://forge.gridforum.org/forum/forum.php?forum_id=570

You can respond in that tracker, or in this one -- perhaps
also by uploading a new version of the document.  When it
is ready for the next step (final editor review), please
indicate that in this tracker.

Thanks.  This will now go to 30-day public comment.  It
might take an extra few days to get announced, since
GGF15 just ended.  We'll post the public comment
tracker link here, and will end public comment 30 days
after the posting.

Here's an updated version of the document, reclassified as
Experimental.  I'll describe below how I've addressed David Snelling's
comments.  I've also made the following updates based on comments
from others:

  - Require support for SSL 3.0 and non-support for SSL 2.0.
  - Added reference to PKCS#10.
  - Added reference to [RFC3820] Section 3.4 for setting the proxy
    certificate subject.

> 1) I would like to know how many independent implementations there
>    are on MyProxy. As a non-WG submission, I feel this is and
>    exceptionally important issue.

See my earlier comment.

> 2) They need to reference RFC2119.

Added.

> 3) With respect to client authentication, they state it is OPTIONAL,
>    but require the the server support Proxies. This should be
>    conditional on the server requiring client
>    authentication. Otherwise it is contradictory.

Clarified that client authentication is REQUIRED for all commands
except 'Get', for which it is OPTIONAL.  Also changed proxy support to
SHOULD.

> 4) The zero byte to pander to a quirk in a proprietary protocol is a
>    non-sense. The WG should negotiate with the GSI implementers and
>    remove this meaningless part of the protocol. Basically it make
>    the GGF look sloppy.

I can't change the deployed protocol, but I removed the reference to
GSI here in hopes that it looks less sloppy.

> 5) Passwords of 8 characters and probably better.

Existing implementations require only 6 characters, so I kept that as
is.  The document says, "servers MAY optionally enforce additional
pass phrase quality policies."

> 6) They need to specify a maximum time for the life time. A
>    implementor of the current spec would need to implement arbitrary
>    precision integers to comply with the specification.

Added "not to exceed one billion seconds" which allows implementations
to use a 32 bit signed integer.

> 7) Is there an end of buffer marker or is it just EOI?

Each message is NULL-terminated.

> 8) With respect to the line order either the client's or the
>    server's obligations should be a MUST. The collection of SHOULDs
>    on both sides leaves an awkward gap.

Changed it to a MUST.

> 9) The Get command text should reference the Proxy RFC.

Done.
 
> 10) The Get command text states "pass phrase protecting the proxy
>     credential". Is it really a proxy credential or can it be a root
>     credential?

It can be a proxy or end entity credential.  I removed "proxy" here.

> 11) On Put again, I would prefer 8 charters.

See #5 above.

> 12) Again a maximum for the maximum is needed.

See #6 above.

> 13) Last paragraph of Put used the term 'delegated', which is never defined.

Removed "delegated".

> 14) In Info. This is the first specification and therefore the term
>     backward compatibility is not needed. The SHOULDs are OK.

Removed mention of backward compatibility.

> 15) The Info command implies that client authentication is
>     required. I would make this the case as a solution to 3. It is
>     very strange to define a specification that clearly allow one
>     it's operations to fail by definition in a fully compliant
>     specification.

Made client authentication required.

> 16) The description of the response suddenly became informal rather
>     than following the pattern of the earlier commands.

Changed it to match the other sections more closely.

Thanks,
Jim

Since this document has sparked a great deal of discussion, I would like to add my comments to the record as the other AD for the relevant Area.

I concur with the decision to support advancement of this document as an experimental track document. This document records the specification of the 
protocol used by the MyProxy implementation of a credential repository. It is not presented as a recommendation for global standardization of 
credential repositories. This is consistent with the intent of the Experimental document track.

I believe it is a benefit to the community for GGF to accept individual submissions documenting details of such widely deployed software using the 
experimental or informational document tracks. Such publication indicates the document has passed a peer review for quality, but does not constitute a
 community recommendation.

Should a community of implementers form behind this protocol as a general credential repository protocol, then formation of a Working Group to develop
 and advance a recommendations track document reflecting the consensus would be appropriate.

Comments if 15 Day GSFG Review from Dave Snelling

1) I would like to know how many independent implementations there are on MyProxy. As a non-WG submission, I feel this is and exceptionally important 
issue.

2) They need to reference RFC2119.

3) With respect to client authentication, they state it is OPTIONAL, but require the the server support Proxies. This should be conditional on the 
server requiring client authentication. Otherwise it is contradictory.

4) The zero byte to pander to a quirk in a proprietary protocol is a non-sense. The WG should negotiate with the GSI implementers and remove this 
meaningless part of the protocol. Basically it make the GGF look sloppy.

5) Passwords of 8 characters and probably better.

6) They need to specify a maximum time for the life time. A implementor of the current spec would need to implement arbitrary precision integers to 
comply with the specification.

7) Is there an end of buffer marker or is it just EOI?

8) With respect to the line order either the client's or the server's obligations should be a MUST. The collection of SHOULDs on both sides leaves an 
awkward gap. 

9) The Get command text should reference the Proxy RFC.

10) The Get command text states "pass phrase protecting the proxy credential". Is it really a proxy credential or can it be a root credential?

11) On Put again, I would prefer 8 charters.

12) Again a maximum for the maximum is needed.

13) Last paragraph of Put used the term 'delegated', which is never defined.

14) In Info. This is the first specification and therefore the term backward compatibility is not needed. The SHOULDs are OK. 

15) The Info command implies that client authentication is required. I would make this the case as a solution to 3. It is very strange to define a 
specification that clearly allow one it's operations to fail by definition in a fully compliant specification.

16) The description of the response suddenly became informal rather than following the pattern of the earlier commands.

In summary, I feel it is clear that this spec has not been through a WG process. I would send it back to the author and encourage either a WG be 
formed or that the author seek a co-author willing to implement the protocol 100% independently. I would not pass this directly to Public Comment as a
 Recommendations document.
 
Dave