Burt,
I like all of the changes you have made, but I think you may have
compromised a bit too much.
o One of the things I liked in the previous version was the existence of
different PROC-TYPES for each of the messages. This has the benefit of
identifying within the PEM boundaries exactly what is contained within
them. Otherwise, in the case of a certificate request for example, the
message looks just like an ordinary PEM message. The only thing that
distinguishes the message is the address in the "to" field, ie a
mailbox, which we have taken great pains to remove from RFC 1113.
Also, there is nothing to keep a maliscious person from putting "valid"
data in the certificate and using it to send/receive mail. Since the
certificate is self-signed, with the issuer subject name correctly set,
unless implementations call out this special case, the certificate could
validate "normally". (In our implementation the certificate could
validate, since in addition to supporting the Internet infrastructure,
we accommodate disjoint infrastructures, rooted by self-signed
certificates. Of course, the user is alerted to the existence of
unexpected self-signed certificates.
I would vote for keeping the CERT-REQUEST, CERT-REPLY, CRL-STORAGE-REQUEST,
CRL-STORAGE-REPLY, CRL-RETRIEVAL-REQUEST, and CRL-RETRIEVAL-REPLY
PROC-TYPE's.
o In each of the "reply" descriptions, you say
the reply includes a certification path to the RFC 1114F
Internet certification authority.
1. I think this should say "the reply *should* include a
certification path".
One common scenario I imagine is that an organization might use
this mechanism for its individual users to get registered. It may
also be true that the organization has a centralized database that
would be used by all users (available via NFS for example). In
this scenario, I would like to be able to process the request but
not return the entire certification path, since it would be
superfluous. (It is also true I would not have to return the new
signed certificate, but the CA does have to reply to the requestor
and this is a good way to do it.) It is also true the
issuer-certificates are not required in messages by RFC 1113E.
2. This document should be independent of the infrastructure proposed
by RFC 1114F. In that respect, the statement above should say
that an appropriate certificate path should be included, for
example to the RFC 1114F Internet certification authority .
o In Section 2.1 you have a paragraph that states the CA signs a
certification only if both signatures are valid. You should also add
a phrase or sentence stating that whatever other requirements the CA
may have are also met (for example the verification of the
out-of-scope forms mentioned earlier).
Looks great! Thanks for providing a new version so quickly in response
to comments.
Jim