Re: [smime] Use of subjectKeyIdentifier

["Jim Schaad" <[e-mail]>]

AMEN.

Jim


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Blake Ramsdell
> Sent: Thursday, April 01, 2010 1:08 AM
> To: Michael Ströder
> Cc: [e-mail]
> Subject: Re: [smime] Use of subjectKeyIdentifier
> 
> 2010/3/31 Michael Ströder <[e-mail]>:
> > Peter Gutmann wrote:
> >> =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/smime