Online Certificate Revocation Protocol

"Mr Jonathan W Jenkyn" <jonathan.jenkyn@interclear.com> Sat, 09 June 2001 01:58 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 VAA23873 for <pkix-archive@odin.ietf.org>; Fri, 8 Jun 2001 21:58:30 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id SAA13164 for ietf-pkix-bks; Fri, 8 Jun 2001 18:21:22 -0700 (PDT)
Received: from cmailg6.svr.pol.co.uk (cmailg6.svr.pol.co.uk [195.92.195.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA13158 for <ietf-pkix@imc.org>; Fri, 8 Jun 2001 18:21:16 -0700 (PDT)
Received: from modem-36.blackbird.dialup.pol.co.uk ([62.137.124.36] helo=lilith) by cmailg6.svr.pol.co.uk with smtp (Exim 3.13 #0) id 158XRG-0006HV-00 for ietf-pkix@imc.org; Sat, 09 Jun 2001 02:21:18 +0100
From: Mr Jonathan W Jenkyn <jonathan.jenkyn@interclear.com>
To: ietf-pkix@imc.org
Subject: Online Certificate Revocation Protocol
Date: Sat, 09 Jun 2001 02:23:03 +0100
Message-ID: <NFBBICHJKLJDDAAFHEEMIEDGCPAA.jonathan.jenkyn@interclear.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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



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.
None of the x.500 DN components really fit into the scheme of being altered
under these circumstances.
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!).

Regards

JJ

Jonathan Jenkyn
Head of Cryptographic Systems
De La Rue InterClear Limited
De La Rue House
Jays Close
Viables
Basingstoke
Hants
RG22

Telephone 01256 487700
Support Desk 01256 487777
http://www.interclear.com

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On
Behalf Of Hansen Wang
Sent: 08 June 2001 23:47
To: Tony Bartoletti
Cc: Housley, Russ; pgut001@cs.auckland.ac.nz; ietf-pkix@imc.org
Subject: Re: Online Certificate Revocation Protocol




> A question:  If one discovers that they have accidently destroyed their
> private key (and there is no evidence of compromise), are they under any
> particular obligation to request revocation?  Is there any liability, or
> other real "downside" to simply getting a new key and keeping mum about
the
> fate of the former key?

Assuming that the entity which lost their private key wanted another
certificate with a new key pair but wanted the same name. What would
happen if their were two certificates in existance with the same name?
Wouldn't the CA not allow this? Or request documentation/proof (maybe
out-of-band methods) of ownership of the name and then the CA would
revoke the previous certificate base on the out-of-band proof and issue
a new one with the same name?

Hansen Wang <hansenw@ece.ubc.ca>