Re: [smime] Use of subjectKeyIdentifier

Michael Ströder <michael@stroeder.com> Thu, 01 April 2010 05:40 UTC

Return-Path: <michael@stroeder.com>
X-Original-To: smime@core3.amsl.com
Delivered-To: smime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6830F3A68BA for <smime@core3.amsl.com>; Wed, 31 Mar 2010 22:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.316
X-Spam-Level:
X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIM+8Gau9n06 for <smime@core3.amsl.com>; Wed, 31 Mar 2010 22:40:54 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 994513A6874 for <smime@ietf.org>; Wed, 31 Mar 2010 22:40:52 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o315fMCD041340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-smime@imc.org>; Wed, 31 Mar 2010 22:41:24 -0700 (MST) (envelope-from michael@stroeder.com)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 5F6584E1A2; Thu, 1 Apr 2010 07:41:20 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmRHsVnESbVR; Thu, 1 Apr 2010 07:41:18 +0200 (CEST)
Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 350954E1A0; Thu, 1 Apr 2010 07:41:16 +0200 (CEST)
Message-ID: <4BB431FC.1040109@stroeder.com>
Date: Thu, 01 Apr 2010 07:41:16 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 SeaMonkey/2.0.4
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <E1Nx6bW-0006W6-7e@wintermute02.cs.auckland.ac.nz>
In-Reply-To: <E1Nx6bW-0006W6-7e@wintermute02.cs.auckland.ac.nz>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: ietf-smime@imc.org
Subject: Re: [smime] Use of subjectKeyIdentifier
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smime>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 05:40:56 -0000

Peter Gutmann wrote:
> =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com> writes:
> 
>> If an S/MIME cert does not contain a subjectKeyIdentifier extension is a
>> sending S/MIME MUA allowed to generate RecipientInfos referencing the
>> receiver's cert by (self-calculated) subjectKeyIdentifier (instead of issuer
>> name and serial number)?
> 
> I think there's a diference here between "can it" and "if it does, will it
> work".  I can't see why an MUA can't do whatever it pleases (within the spec),
> but then since the sKID is an implicit identifier (i.e. it's "whatever binary
> blob is stored within the cert") rather than an explicit one ("you can
> generate an unambiguous sKID by doing ..."), it's more or less pot luck as to
> whether the recipient will end up with the same sKID.

Just to clarify: I'm trying to track down an interop issue.

This is a problem with Outlook 2010 beta sending subjectKeyIdentifier in
RecipientInfos although my e-mail cert does not contain the
subjectKeyIdentifier extension. Seamonkey is not able to find my accompanying
e-mail cert and private key based on that and thus is not able to decrypt the
S/MIME message.

In theory one could even determine one of the commonly used algorithms by
looking at the key id size. But I'd prefer to have a good argument that
Outlook 2010 violates a standard.

RFC 5652, section 6.2.1 says:

      [..] the subjectKeyIdentifier identifies the
      recipient's certificate by a key identifier.  When an X.509
      certificate is referenced, the key identifier matches the X.509
      subjectKeyIdentifier extension value.  When other certificate
      formats are referenced, the documents that specify the certificate
      format and their use with the CMS must include details on matching
      the key identifier to the appropriate certificate field.  For
      recipient processing, implementations MUST support both of these
      alternatives for specifying the recipient's certificate.  For
      sender processing, implementations MUST support at least one of
      these alternatives.

But still that's IMO not really clear for the case the e-mail certs does not
contain the subjectKeyIdentifier extension.

Ciao, Michael.