RE: New CMC Draft available - Confirmation Message

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Yes.

Although revoking a certificate that the client has already started 
to use is awkward, it is at least fail safe. If someone receives 
a document that can't be validated they will go back to the user and 
complain, and the matter will be resolved quickly. But the other 
way around risks having a certificate published that was issued 
to the wrong person, or that the client doesn't accept because 
of the contents, etc.

One way to make this a little more graceful is to use the pending state, 
where the certificate is not published until it is accepted, and can
not be used to validate the certificate the client has already received
until the notice of acceptance has been received, e.g., in the form 
of a secret PIN sent out of band to that user to indicate acceptance.
This PIN can also be used to prove that the user actually saw and
read the notice of certificate issuance.

Regards,

Bob

>>> "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> 04/23/99 10:02AM >>>
Let me make sure that I understand what you are saying:

It is better for both the CA and the client, for a CA to revoke a
certificate that the CA has not received positive conformation of acceptance
(even if the client thinks it has accepted it and started to use it) than it
is for a CA to not revoke a certificate that a client has rejected.
Remember that for signing certificates the client can start using the cert
immeadiately and does not need to wait for it to be published in the DS.

jim


-----Original Message-----
From: Bob Jueneman [mailto:BJUENEMAN@novell.com] 
Sent: Friday, April 16, 1999 3:38 PM
To: Jim Schaad (Exchange); 'walter@deh.de' ; IETF-PKIX (E-mail)
Subject: RE: New CMC Draft available - Confirmation Message


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