Re: [smime] Use of subjectKeyIdentifier

[Blake Ramsdell <[e-mail]>]

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