Simplest RFC?

Which is the simplest RFC? Maybe this one: http://tools.ietf.org/html/rfc863

DISCARD: the server just discards all received messages.

MyProxy and proxy certificate

All of following discussion is based on PKI (public key infrastructure).

What's important in terms of security?
integrity of the user's identity credential(certificate + public/private key pair).
Note: What is important is not just a single part of the credential, but also integrity of different parts. If a certain component is compromised, the whole credential is not secure any more.

how to protect private key?
(1) Store it in desktop
May not be a good idea because usaually desktop is not protected professionally. It is vulnerable to keystrok loggers, trojan ...
(2) Smart card
A specific piece of hardware provides improved security for key storage.
Pros: allows keys to be used for signing and encryption without allowing the keys to be exported from the card's protected memory.
Cons: cost and support
(3) Virtual smart card
Similar to the physical smart card approach. It is a software system which protects private keys on secure servers without allowing the keys to be exported.

Grid computing
Usually, the user has a certificate issued by a CA and it has long life time (maybe several years). Before successul running of a task, the certificate must be authenticated by grid infrastructure. Tasks may be submitted and launched from different hosts.
(*) So it is not convenient to ask users to copy their credentials manually across different machines.
(*) It is not secure to put long-term credentials to many hosts in the grid.
It would be great if users can obtain a short-time(hours or days) credential which can be used for authentication during execution of a task.
There are two solutions:
(1) Online CA
Every time the user needs a short-time credential, he/she just sends certificate request to CA and CA returns the newly created certificate.
Drawback: cost. Adding a new CA needs a lot of extra work in terms of time, money, negotiating policies...
(2) Online credential repository
This solution makes use of X.509 proxy certificate described below. 
MyProxy uses the third approach.

Proxy Certificate (RFC 3820)
Key idea: An entity delegates its rights or a subset of its rights to another entity which can behave on behalf of the original entity.
Security
Restrictions can be placed on the PC be means of policies.
Terminology
EEC(End Entity Certificate): an X.509 Public Key Certificate issued to an end entity by a CA.
PC(Proxy Certificate): can be issued by EEC or another PC.
PI(Proxy Issuer): an entity with an EEC or PC that issues a PC. The issued PC is signed using the corresponding private key.
Properties of PC
(*) Signed by EEC or PC
(*) It can sign another PC. Cannot sign EEC
(*) Its public/private key pair is different from that of the proxy issuer.
(*) Its identity is derived from identity of the original ECC that signed the PC.
Note: its identity is unique so that it can be used as an independent identity.
(*) It contains a new X.509 extension to indicate that it is a PC and to place restrictions on use of the PC.
Procedure
If an entity A wants to delegate its rights to entity B, the procedure is
(1) Entity B creates a private/public key pair
(2) Entity B creates a request for a PC and sends it to entity A
(3) Entity A creates a PC, singed by the private key of A's certificate (EEC or another PC).
In this process, restrictions can be placed on the newly created PC. For example, validity period...
(4) Entity A sends the certificate back to entity B.
Note: the private key of entity A is stored on the local file system.
Significant advantages
Private keys are never transferred over the internet.

How MyProxy works?
Proxy storing
This is similar to the procedure described above in section <Proxy Certificate> / <Procedure>. Entity A is the end user and entity B is MyProxy server. In step (4), end user sends both the newly created Proxy Certificate and the entire certificate chain to the server. Also access control can be imposed by means described below.
Proxy retrieval
Similar to proxy storing, except in reverse. Access control policies must be checked to see whether the client is allowed to retrieve the certificate.
Access Control
Server administrator can control who can store/retrieve credentials by:
    (1) Requiring client-side TLS authentication
    (2) Configuring a regular expression that must match the client certificate's subject for storage requests
    (3) Configuring a regular expression that must match the client certificate's subject for retrieval requests
Credential owner can control access to their certificates by :
    (1) setting a password when storing the certificates
     The password is not stored in the server. It is used to encrypt server's private key which would be used to sign the proxy certificates.
    (2) settting regular expression on the client certificate's subject that would retrieve the certificate.
Renewal
    to be filled soon

To be investigated in the future
MyProxy and OGSI (Open Grid Services Infrastructure):
    MyProxy is encapsulated as web services.
MyProxy and WS-Resource Framework

Uniform Resource Identifier(URI) and Uniform Resource Locators (URL) - (RFC 1738 and RFC 3986)

Character Escape
URI consists of a set of characters.
uric = reserved | unreserved | escaped

Reserved characters
Principle: a character is reserved if the semantics of the URI changes if the character is replaced with its escaped escaped encoding.

    gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"
    sub-delims  = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

Their usage within URI component is limited to their reserved purpose. If the data would conflict with the reserved purpose, it must be escaped.
Characters in the "reserved" set are NOT reserved in all contexts. The reserved characters in a URI component is defined by that specific component.

Unreserved characters
a-z A-z 0-9 "-" "_" "." "~"
These characters can be escaped WITHOUT changing the semantics of the URI.
But this should NOT be done UNLESS the escape is necessary.

Disallowed characters
Some characters are disallowed for various reasons. To use those characters, they MUST be escaped.
Disallowed US-ASCII Characters:
control:      <US-ASCII coded characters 0x00-0x1F and 0x7F>
space:        <US-ASCII coded character 0x20>
delimiters:  < > # % "
unwise:       { } | \ ^ [ ] `

When to escape?
When a character does not have a representation using an unreserved character, it must be escaped. It includes:
(1) data that does not correspond to printable characters (ANSII coding)
(2) disallowed characters
Note: here, whether a character is unreserved is context-specific.

Escape sequences:
A "%" followed by hex representation of the character.
escaped = "%" hex hex
E.g. %20 %35
Uppercase hexadecimal digits should be used in percent-encoding!

Syntax
Generic URI syntax: 
    <scheme>:<scheme-specific-part>
Interpretation of scheme-specific-part depends on the scheme.
    <scheme>://<authority><path>?<query>

scheme
    alpha *( alpha | digit | "+" | "-" | "." )

authority
URI component authority can be internet-based server or a scheme-specific registry.
authority (server based) = username@host:port
userinfo = *( unreserved | escaped |";" | ":" | "&" | "=" | "+" | "$" | "," )
About domain label:

"The rightmost domain label of a fully qualified domain name will never start with a digit, thus syntactically distinguishing domain names from IPv4 addresses, and may be followed by a single "." if it is necessary to distinguish between the complete domain name and any local domain."

Query
query = *uric
Within a query component, the characters ";", "/", "?", ":", "@", "&", "=", "+", ",", and "$" are reserved.

Fragment
Fragment is not part of a URI, but is often used in conjunction with a URI.
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

from RFC 2396:
"The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference.
   A fragment identifier is only meaningful when a URI reference is intended for retrieval and the result of that retrieval is a document for which the identified fragment is consistently defined."

Relative URI reference
to be continued in the future.

Specific schemes

scheme	syntax	Explanation	Note
file	file://<host>/<path>	Access a file on a specific host. <host> can be "localhost" or empty to indicate local host. E.g. file:///usr/home	Unlike http and ftp, It does not specify an internet protocol to access the files.
ftp	ftp://<host>:<port>/ <cwd1>/<cwd2>/.../<cwdN>/ <name>;type=<typecode>	<cwd1> through <cwdN> are strings and <typecode> can be "a", "i" or "d". If <typecode> is "d", <name> is used as the argument of NLIST command.	Within the <name> or a CWD component, / and ; must be escaped. E.g. ftp://test.com/%2Froot/a.txt
mailto	mailto:<mail-address>	RFC 2822 specifies the format of internet messages.	Usually, "%" must be escaped.
http	http://<host>:<port>/ <path>?<query>

Resources
URI working group: http://labs.apache.org/webarch/uri/

Time and date (ISO 8601, RFC 3339, W3C)

Illustration by examples.
(1) ISO 8601
Because the specification also supports rarely-used features, I will not give an exhaustive description. I would like to give some common examples.
(*) Date

Use month and day
YYYY-MM-DD	2008-07-08	MM:01 - 12 DD: 01-31
YYYY-MM	2008-07	Seconds are omitted. ( YYYYMM is not allowed )
YYYY	2008
YYYYMMDD	20080708	hyphens are omitted
Use week and day in a week
YYYY-Www-d	2008-W01-1	ww: week number(01-52/53) d:day in the week(1-7)
YYYY-Www	2008-W01	first week in 2008
YYYYWwwd	2008W011
YYYYWww	2008W01
Use day in the year
YYYY-ddd	2008-014	ddd: day in the year 000 - 365(366 in leap years)
YYYYddd	2008123

(*)Time

hh:mm:ss	16:23:42	hh: hour (00 - 24) mm:minute(00-59) ss:second(00-60)
hhmmss	162342	colons are omitted
hh:mm	16:23	seconds are omitted
hhmm	1623
hh	16	both minutes and seconds are omitted
hh:mm:ss.mil	16:23:42.123	More precise

(*)Time zone

hh:mm:ssZ	12:23:43Z	'Z' means the time is measured in UTC.
time+hh:mm	13:23+01:00	The time is hh hours and mm minutes ahead of UTC
time+hhmm	13:23+0100	colon is omitted.
time+hh	13:23+01	The time is hh hours ahead of UTC
time-hh:mm time-hhmm time-hh	11:23-01:00 11:23-0100 11:23-01	The time is after UTC. The zone is in west of the zero meridian.

(*) Put together

<date>T<time>	2008-02-12T12:23:34 20080212T122334 2008T1223
<data>T<time>Z	2008-02-12T12:23:34Z
<data>T<time>+<zone>	2008-02-12T13:23:34+01
<data>T<time>-<zone>	2008-02-12T11:23:34-01

Resources:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
http://en.wikipedia.org/wiki/ISO_8601

(2) RFC 3339
This is a profile of ISO 8601 which defines date and time to be used on internet.
Following is excerpt from the specification:

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                             ; rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

(3) W3C
W3C also defines a profile of ISO 8601 which can be accessed here.