Dear Jim --
Thanks for your comments on the latest [FORMS] revision.
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
Well, there's nothing to prevent a malicious person from doing this
independent of what [FORMS] says, but I see your point.
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.
CERT-REPLY is intended to be MIC-ONLY or MIC-CLEAR; it really is PEM.
Same for CRL-RETRIEVAL-REPLY; it's intended to be CRL.
CRL-STORAGE-REQUEST is CRL; CRL-STORAGE-REPLY is non-PEM (just "Done.").
CRL-RETRIEVAL-REQUEST is a new syntax.
The only issue for vote (as I see it) is whether certification
requests should be CERT-REQUEST, or an overload of MIC-ONLY/MIC-CLEAR.
1. I think this should say "the reply *should* include a
certification path".
You're right, we should leave the definition of certification path to
the PCA ...
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 .
Good point; I agree.
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).
Agreed again.
-- Burt