Re: New CMC Draft available - Confirmation Message

[Juergen Walter <walter@xxxxxx>]

Carlisle, Jim

Comments in line.

"Jim Schaad (Exchange)" wrote:
> 
> Juergen,
> 
> The problem that I have with this approach is that there is no way of
> knowing what the delay is going to be on the acceptance showing up on at the
> CA.  (Nor do all transport mechinisms guantee delivery.)  Thus a client can
> think it did accept a certificate and the CA can reach an opposite
> conclusion.  If the client asks for revocation, it can later check to make
> sure that this operation occured.

As Carlisle mentioned I prefer to publish the certificate in a
repository (database, directory, OCSP server) after the client had
explicitly confirmed when required. Whether the repository is public or
intended for a closed user group it doesnīt matter, at least the client
itself should have access to its own certificate (status information).
In PKIs there no repository exists one may use the certification
announcement message for that purpose. In both cases the client may
check its confirmation.

I agree with Jim that a rejected certificate has to be revoked even if
has not been published yet when it was sent to the client. The
revocation request message is sufficiently, when we consider PKIs where
no confirmation message is required. But if this explicite confirmation
is required, no message format is available in the current CMP draft.
The first application of the issued certificate e. g. in a signned
S/MIME message may indicate clients confirmation why the certificate is
enclosed in the S/MIME message. Is this an explicite confirmation? I am
not sure.

Alternatively, the client may send its certificate to a repository. If
the repository is triggered by clients "publication request" then it may
be an explicite confirmation. Have we specified or planned an
appropriate message yet? The current publication info is contained in
the certification request before the certificate is issued, isnīt it? 

I would like to propose that the confirmation message in CMP should be
replaced by a message that allows the client to confirm explicitly or to
reject its certificate if appropriate. I believe that the current
protocol design of CMP:
1: initial request: EE -> CA
2: initial response: CA -> EE
3: confirmation: EE -> CA when confirmed,
3ī: revocation request: CA -> EE when rejected
...
may be improved by the proposed new message.   

Last but not least. Have we already specified an appropriate revocation
reason that may occur after certificate issuing when the revocation
request is applied?

Juergen

[snip]