Re: [smime] Use of subjectKeyIdentifier

"Jim Schaad" <> Thu, 01 April 2010 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCC983A6A3E for <>; Thu, 1 Apr 2010 09:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.616
X-Spam-Status: No, score=-4.616 tagged_above=-999 required=5 tests=[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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DRo0xmkWMFQJ for <>; Thu, 1 Apr 2010 09:45:13 -0700 (PDT)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id 70B0A3A6A47 for <>; Thu, 1 Apr 2010 09:45:13 -0700 (PDT)
Received: from ( []) by (8.14.2/8.14.2) with ESMTP id o31GjiDM083889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Thu, 1 Apr 2010 09:45:45 -0700 (MST) (envelope-from
Received: from TITUS (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTP id CD2106A444; Thu, 1 Apr 2010 09:45:42 -0700 (PDT)
From: "Jim Schaad" <>
To: "'Blake Ramsdell'" <>, "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <>
References: <> <> <>
In-Reply-To: <>
Date: Thu, 1 Apr 2010 09:45:38 -0700
Message-ID: <049201cad1ba$c3009d00$4901d700$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrRcuC2FC0IMTCYQNmmbXN7p5gRQAAR9rpA
Content-Language: en-us
Subject: Re: [smime] Use of subjectKeyIdentifier
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SMIME Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Apr 2010 16:45:14 -0000



> -----Original Message-----
> From: [] On Behalf
> Of Blake Ramsdell
> Sent: Thursday, April 01, 2010 1:08 AM
> To: Michael Ströder
> Cc:
> Subject: Re: [smime] Use of subjectKeyIdentifier
> 2010/3/31 Michael Ströder <>om>:
> > Peter Gutmann wrote:
> >> =?ISO-8859-1?Q?Michael_Str=F6der?= <> 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.
> And I agree with this. The short answer is that even though none of
> the specs say that generating your own sKID and trying to match that
> up to a certificate that doesn't have a sKID in it is a bad idea, the
> implied use is that you identify a certificate by sKID when you
> grabbed that sKID out of the certificate extension.
> The second that you might think that it's a good idea to generate an
> sKID on the fly, in the hopes of matching it back up with the
> certificate from which it is derived (that does not have the
> extension), you might read section of RFC 5280 and see that
> there are multiple uses of the word SHOULD as well as multiple
> alternatives for computation, which should then give you pause that
> "Hm. Maybe I shouldn't go down this path. Something is not right."
> But indeed, it never says the words "don't generate a sKID in the
> hopes of matching it back up with a certificate that doesn't have that
> extension." But the terrible smells in the area surrounding how sKIDs
> can be generated (which includes "Other methods of generating unique
> numbers are also acceptable") should be enough to make you want to
> pick another direction ;). As Peter points out, it's a binary blob
> that (if you're lucky) was generated in a deterministic way based on
> the public key and (if you're not) it's a counter or random value or
> hash or MPEG of a cat.
> > 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.
> That's bad. If Outlook 2010 is doing this, it's bad, for the reasons
> that Russ, Peter and I are pointing out. Generating an sKID for a
> certificate that doesn't have one is the wrong path, you must use
> issuerAndSerialNumber to identify the certificate in this case, and
> then make a very frowny face at the CA that generated the certificate
> for ignoring the SHOULD in section of RFC 5280 "To assist
> applications in identifying the appropriate end entity certificate,
> this extension SHOULD be included in all end entity certificates"
> which is why we're here now.
> > 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.
> I don't think we're going to find a "MUST NOT try to guess an sKID if
> a certificate does not have one" anywhere, but I think there's one and
> a half implementors that are chiming in right now and saying "OMG,
> that is totally creepy and isn't really going to work".
> Now, I can see from an implementation point of view that you might
> think "dangit, I really don't want to support both
> subjectKeyIdentifier and issuerAndSerialNumber in SignerIdentifier and
> RecipientIdentifier" and then try to do something like, I dunno,
> generate an sKID for a certificate that doesn't have that attribute,
> and then use the sKID CHOICE in those structures. I think we've
> discussed that's bad (now the receiver has to jump through the same
> hoops and hopefully generates the same sKID that you did, which
> exactly zero implementations do right now).
> So if that's what Outlook 2010 beta is doing, I think I'd want to hear
> a medium length explanation about why this is the case. Because any
> other implementation is going to see an sKID and then try to look up a
> certificate that matches that sKID and fail (since there's no
> certificate that contains that extension). They won't attempt to use
> every known sKID generation algorithm currently known to try and
> synthesize one, they'll just give up. I don't blame 'em, and I think
> it's not a good idea to attempt.
> >
> > 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.
> This is a great section to quote. Sure it is -- it says "matches the
> X.509 subjectKeyIdentifier extension value". The value that's in the
> extension. If the extension isn't present, it doesn't say "if it's not
> present, synthesize one".
> If Outlook 2010 is really generating an sKID for a certificate that
> doesn't have one, I think that we can find a large number of
> implementors who will disagree with that strategy.
> Bottom line -- if there's no subjectKeyIdentifier, you use
> issuerAndSerialNumber, don't try and generate your own
> subjectKeyIdentifier.
> Blake
> _______________________________________________
> smime mailing list