On Tuesday, December 02, 1997 7:07 AM, dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil
[SMTP:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil] wrote:
If this working group takes on this task, (I think it would be more
appropriate within the PKIX WG, but like Mike, don't have any strong
objection to pursuing it here - many of the participants are members
of both groups), then it MUST ensure that the result is compatible
with PKIX, not an independent and incompatible protocol based on
straight unmodified PKCS#10.
I agree. This whole thing has caught me kind of off guard as a behind
the scenes effort. I am still trying to sort out the spec and figure
out what exactly can't be accomplished with existing protocols
(specifically CMP) by constraining those protocols to fit in our
profile, and/or modifying them to fix any shortcomings that make them
unsuitable for our profile (non-persistent connections, etc.)
Note the key last sentence - "an interpretation of PKIX-3 messages over
PKCS7". This means that any usage of PKCS#10 certificate requests MUST
be in the form of PKIX-3 "p10cr" messages, in order to allow implementors
to quickly develop "Basic functionality" certificate request messages
based on existing technology, while remaining compatible with, and allowing
smooth migration to, the "Full functionality" (and more difficult to
implement) CMP.
I agree, and this option was discussed in an earlier thread also I
believe.
If this WG adds a certificate request work item to it's charter, it
should be clearly stated that the result must be compatible with
PKIX CMP, not an independent, non-interoperable syntax based on raw
PKCS#10.
If there are problems with CMP then we should fix them. Coming up with
a new protocol is fun, but I think it fragments the effort. I will read
the CRS spec more closely to find out what the differences are, but I
think that CMP can be fixed to satisfy our needs. From my
understanding, CMP is in last call, but I really think we should fix it
right, and I think that "right" means fixing CMP if it is broken and
can't be used for S/MIME.
There may certainly be issues and forces at work here that I don't
understand, and someone should feel free to correct me if I am too
unenlightened to see the value in having a separate incompatible
specification instead of a profile constraint on (potentially modified)
PKIX CMP.
Blake