Re: [smime] Use of subjectKeyIdentifier

"Jim Schaad" <ietf@augustcellars.com> Thu, 01 April 2010 16:45 UTC

Return-Path: <ietf@augustcellars.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 CCC983A6A3E for <smime@core3.amsl.com>; Thu, 1 Apr 2010 09:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.616
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRo0xmkWMFQJ for <smime@core3.amsl.com>; Thu, 1 Apr 2010 09:45:13 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 70B0A3A6A47 for <smime@ietf.org>; Thu, 1 Apr 2010 09:45:13 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o31GjiDM083889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <ietf-smime@imc.org>; Thu, 1 Apr 2010 09:45:45 -0700 (MST) (envelope-from ietf@augustcellars.com)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id CD2106A444; Thu, 1 Apr 2010 09:45:42 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Blake Ramsdell'" <blaker@gmail.com>, "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <michael@stroeder.com>
References: <E1Nx6bW-0006W6-7e@wintermute02.cs.auckland.ac.nz> <4BB431FC.1040109@stroeder.com> <m2i985966521004010108v4af43fe5y72699efb45e5a6db@mail.gmail.com>
In-Reply-To: <m2i985966521004010108v4af43fe5y72699efb45e5a6db@mail.gmail.com>
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
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 16:45:14 -0000

AMEN.

Jim


> -----Original Message-----
> From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf
> Of Blake Ramsdell
> Sent: Thursday, April 01, 2010 1:08 AM
> To: Michael Ströder
> Cc: ietf-smime@imc.org
> Subject: Re: [smime] Use of subjectKeyIdentifier
> 
> 2010/3/31 Michael Ströder <michael@stroeder.com>om>:
> > 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.
> 
> 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 4.2.1.2 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 4.2.1.2 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
> smime@ietf.org
> https://www.ietf.org/mailman/listinfo/smime