Subject: RE: New CMC Draft available - Confirmation Message

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Tue, 13 Apr 1999 12:01:31 -0700

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.

jim

-----Original Message-----
From: Juergen Walter [mailto:[email-masked]]
Sent: Tuesday, April 13, 1999 1:32 AM
To: Jim Schaad (Exchange); IETF-PKIX (E-mail)
Subject: Re: New CMC Draft available - Confirmation Message

Jim,

[snip]

> 
> > - there is no confirmation message from the client to the
> > CA/RA (thus, there
> > is no way for a client to reject a certificate that it does
> > not want (e.g.,
> > in the case where the CA has modified some of the fields in
> > the request)).
> 
> There is a simple way for a client to reject a certificate, it simply puts
> in a revocation request on the certificates it just received.  I don't
know
> of any reason for the oppositite to be required in a general protocal.
That
> is the client must positively accept a certificate.
> 

When I remember right e. g. ABA Guidelines requires that an EE
explicitly confirms an issued certificate. This may be not a protocol
requirement in pure PKI implementations. But I know environments where a
certificate receipt is at least an operational requirement. I think that
an appropriate message (optional) would be an improvement. When the
rejection (i. e. sending of revocation request) stays away we have no
explicite confirmation of the certificate (may be a legal issue). The
time-frame of such stay away process may cause complicated validation
issues. I prefer a message that indicates the fact whether an EE accept
his certificate or not. This may replace the revocation request on the
one hand and the pure revocation request on the other hand. 

Juergen

---

From: Juergen Walter <[email-masked]>
Date: Wed, 14 Apr 1999 10:59:43 +0200

Carlisle, Jim

Comments in line.

> 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]