Re: [smime] Use of subjectKeyIdentifier

[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.

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.