PKIX-CMP

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi,

I have just submitted PKIX Certificate Management Protocols (used to be
PKIX-3, but it was agreed in Munich that part numbers were to be removed
from the various documents) to the Internet-Drafts address  -- it should
show up soon at the usual repositories.

I believe this draft is now ready for last call, as agreed in Munich and
reiterated (after some debate) recently on this list, and have asked the
chairs to issue this call once the document is readily available.


The changes incorporated are as follows.

1) Centralized key generation (i.e., at the CA) is now optional; the
"basic authenticated scheme" is the only mandatory initialization
scheme.

2) It is noted (see pages 10 and 21) that a general key generation
request/response protocol, and that a PKCS #7 protection mechanism, may
be specified in separate documents.

3) AlgIDs, references, and modulus lengths (where appropriate) have been
given for all mandatory algorithms in Appendix B; see p.49.

4) In re-reading Section 4, I discovered that we were mandating
"certificate update" (a new certificate for an existing key) as opposed
to "key update" (a new certificate for a new key); see p.40 of the
previous draft.
[A slight cut-and-paste error that must have happened ages ago  --  I'm
surprised no one noticed this earlier...]  This has been fixed (and
Appendix B has been updated to support this).

5) Charles Moore requested hooks for extensibility in the PKIBody (this
was also requested by Russ Housley in a later message to the list).  It
turns out that the extensibility was already there; it just wasn't
obvious.  (The PKIInfoReqContent and PKIInfoRepContent bodies are SETs
of {OID,value} pairs and so immediately fill the requirement.)  I have
renamed these to GenReqContent and GenRepContent to emphasize their
general nature and have explicitly stated (see p.35) that these may be
used to define new request and response messages for future needs or for
specific environments.

6) Rich Ankney, in conjunction with the above, requested extensibility
in the individual messages as well, either in PKIHeader or in each
PKIBody.  It seemed to make more sense to put it in the header, so I
have added an OPTIONAL SET OF {OID,value} pairs there.


That's it, other than general editing/formatting/typo cleanup.


--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------

>