Subject: RE: New CMC Draft available - Confirmation Message

From: Carlisle Adams <[email-masked]>
Date: Tue, 13 Apr 1999 15:58:23 -0400

Hi Jim,

> ----------
> From: 	Jim Schaad (Exchange)[SMTP:[email-masked]]
> Sent: 	Tuesday, April 13, 1999 3:01 PM
> To: 	[email-masked]'; IETF-PKIX (E-mail)
> Subject: 	RE: New CMC Draft available - Confirmation Message
> 
> 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.
 
Note that if client acceptance is the trigger for CA publication of the
certificate, it is still the case that the client can later check to make
sure that its confirmation message was received (i.e., by looking wherever
certs get posted).

Uncertainties on the client end notwithstanding, Juergen makes a good point
(which I forgot to mention in my previous posting on CMC comments):  some
environments require the CA to receive an explicit acceptance from the
client in order to treat the certificate as "ready for use" and to issue it
publicly.  (This may be for legal, liability, or other reasons.)  A
confirmation message is a useful way to satisfy that requirement within the
protocol.

Carlisle.

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 16 Apr 1999 16:38:00 -0600

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)" <[email-masked]> 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:[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: "Jim Schaad (Exchange)" <[email-masked]>
Date: Fri, 23 Apr 1999 09:02:33 -0700

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:[email-masked]]
Sent: Friday, April 16, 1999 3:38 PM
To: Jim Schaad (Exchange); [email-masked]' ; IETF-PKIX (E-mail)
Subject: RE: New CMC Draft available - Confirmation Message

Jim,

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

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]

know
That

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: "Bob Jueneman" <[email-masked]>
Date: Fri, 23 Apr 1999 12:33:32 -0600

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)" <[email-masked]> 04/23/99 10:02AM >>>

jim

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Friday, April 16, 1999 3:38 PM
To: Jim Schaad (Exchange); [email-masked]' ; IETF-PKIX (E-mail)
Subject: RE: New CMC Draft available - Confirmation Message

Jim,

Bob

Juergen,

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]

know
That

Juergen