RE: New CMC Draft available - Confirmation Message

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Jim,

I have to agree with Juergan.

The client shouldn't have to check for revocation if (s)he disagrees with the
certificate, even though it might be prudent to do so.

But if the client does accept the certificate and the CA thinks it hasn't, that 
is at least fail safe.

If the CA ends up calling the client, screaming "What do you mean you are 
rejecting the certificate -- do you want to keep on working here?!", then
at least the problem will end up getting resolved.

But if the client thinks it rejected the certificate and the CA goes ahead 
and publishes it anyway, very real and perhaps substantial damages could
occur - it might be someone else's public key, it might disclose private information,
or it might contain a Reliance Limit that is higher than the client wishes to accept., etc.

Positive acknowledgment of acceptance by the Subscriber is a firm requirement.

Bob


>>> "Jim Schaad (Exchange)" <jimsch@exchange.microsoft.com> 04/13/99 01:01PM >>>
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:walter@deh.de] 
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