Re: Online Certificate Revocation Protocol

Hansen Wang <hansen.wang@home.com> Sat, 09 June 2001 03:04 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25189 for <pkix-archive@odin.ietf.org>; Fri, 8 Jun 2001 23:04:05 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id TAA15804 for ietf-pkix-bks; Fri, 8 Jun 2001 19:27:43 -0700 (PDT)
Received: from mail2.rdc2.bc.home.com (mail2.rdc2.bc.home.com [24.2.10.85]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA15794 for <ietf-pkix@imc.org>; Fri, 8 Jun 2001 19:27:34 -0700 (PDT)
Received: from home.com ([24.76.94.62]) by mail2.rdc2.bc.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010609004138.DJR862.mail2.rdc2.bc.home.com@home.com>; Fri, 8 Jun 2001 17:41:38 -0700
Message-ID: <3B216FAC.8BCBD2B1@home.com>
Date: Fri, 08 Jun 2001 17:37:00 -0700
From: Hansen Wang <hansen.wang@home.com>
Reply-To: hansenw@ece.ubc.ca
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Mr Jonathan W Jenkyn <jonathan.jenkyn@interclear.com>
CC: hansenw@ece.ubc.ca, Tony Bartoletti <azb@llnl.gov>, "Housley, Russ" <rhousley@rsasecurity.com>, pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org
Subject: Re: Online Certificate Revocation Protocol
References: <NFBBICHJKLJDDAAFHEEMIEDFCPAA.jonathan.jenkyn@interclear.com>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
Content-Transfer-Encoding: 7bit

  Tony Bartoletti wrote:

  > I don't think so.  X.509 supports "key-implies-name".  You are
suggesting
  > that it also supports "name-implies-key".  I don't believe there is
such a
  > restriction in general (although a CA may decide per policy).
  > 
  > Is there some specific threat enabled if the key/name relation is
many-to-one?

  Mr Jonathan W Jenkyn wrote:
  > 
  > What is it you are trying to guard against here? Is it that the CSP
would be
  > confused by the existence of two certificates with the same Subject
and
  > Issuing DN? The inclusion of
SubjectKeyIdentifier/AuthorityKeyIdentifier
  > would guard against this, and would still allow the client to have a
  > certificate with the same DN. Also the Serial number should also be
  > distinct, providing a visible mechanism for recipients of the
certificate to
  > discern between the two certificates.

OK, I get it now. 

> After consideration, if the client had 2 key pairs one for signing/verify,
> the other for decrypt/encrypt (the latter also held by the clients
> organisation). Could not the clients organisation (under an instruction from
> the client) request that the original signing key pair be revoked by
> utilising the decrypting/encrypting key pair? Thereby passing responsibility
> for revocation validation to the clients organisation (a better form of
> authentication than a hotline!).
> 

But wouldn't the client keep both key pairs in the same host/computer
and so if the host/computer were stolen, both private keys would be
unavailable. -A reason to make a backup of the private key where
possible? 

Hansen