What problem does BCC Encrypted E-mail forking solve?

BCC forking addresses an issue which has been known for some time: ID's of all recipients of an encrypted message are listed in the certificate list accompanying the message. This way, even if you keep all the recipients in the BCC list, they all appear back in thse certificate list and cethe intended confidentiality is lost! The issue is commonly addressed by simply not showing the certificate list to the user. This is not a very secure method of keeping the recipient list confidential, when anybody can check the certificate list and identify them. If you want to keep the recipients' identities confidential you will have to use one of the two solutions offered by OWA 2K3: BCC forking or Using Key Identifier.

Switching BCC Forking on, gets OWA prepare a separate instance of the encrypted message for each recipient. This way, each copy has only one recipient and confidentiality is kept. Of course the OWA client has to send each copy to the server. This doesn't sound so good with heavy message sent by a roaming user typical to the OWA. This is probably why BCC forking can only be switched on and off by the administrator. After sending the first 10MB encrypted message to 10 recipients any OWA user would switch this forking feature off, either permanently or at least when sending large messages. The ideal way to solve the problem of multiply sent messages would be to implement BCC-forking in the server. This is, at least partially, possible and hopefully will be implemented in the next releases of OWA.

Another solution of the not-so-confidential-recipient-list issue is to turn on the Use Key Identifier feature. This is the feature's short description provided in the OWA administration panel:

"By default, when encrypting e-mail, Outlook Web Access will encode the lockbox where the asymmetrically encrypted token that is necessary to decrypt the rest of the message is stored by indicating the issuer and serial number of each recipient's certificate. This can then be used to locate the certificate and private key for decrypting the message."

OWA Web Administration Tool -> S/MIME ->Use Key Identifier

You would think that the author tried to encrypt this description. We would say that he almost succeeded, so let's try to decrypt it. In short, OWA adds recipients' certificates ID to any encrypted message by default. The certificates ID's can be used to reveal all recipients' identity. This may be a security threat in some situations, as we observed earlier. To avoid this, the administrator can decide to use Key IDs in place of certificate IDs. Key IDs do not reveal much about the recipient as they cannot be used to retrieve an unknown certificate. This is in contrast with the certificate ID, containing the certificate's serial number and issuer ID. The main problem with using the Key ID is that causes interoperability issues: non-OWA clients handle KeyIDs poorly. Another problem is that users with key IDs known to the person wanting to reveal their identity can be identified.

Summing up, there is no easy way to escape the problem of revealing recipients' identity with encrypted messages. Either the user will have to send encrypted messages multiple times (with BCC forking) or you run the risk of getting the message undecrypted by the recipients outside the organisation (with KeyID). However, if keeping recipients' identity confidential is a part of your security policy you'll have to decide on either of the two methods.

See also: 
Correcting Privacy Violations in Blind-Carbon-Copy (BCC)Encrypted Email  _{by Adam Barth and Dan Boneh}

Following screenshots display a practical realisation of the scenarios described. We start with Alice sending an encrypted email to Bob. She would like Dave to get a copy of the message, but without letting Bob know, so she puts Dave in the BCC list.
 

Bob received the message and even viewed the photo included, but was suspicious that he is not the only recipient. He dragged the message from Outlook into p7mViewer, to check the recipients and ... Bingo! Dave's certificate is there, lurking in the certificate list. The only reason for that situation is Alice including Dave in the BCC recipient list, which matches truth. Shame on you, Alice!

In fact, even if Bob didn't know Dave's certificate, he could learn that there was somebody else in the recipient list, as an unknown recipient would be shown in the recipient list:

Does Bob have the possibility to find out whom does the certificate 0x34678 belong to?

Usually public CA allow to find the certificate by identifying its serial number. Alice, Bob and Dave use Certum services and in such case the situation looks as follows:

https://www.certum.pl/services/search.html?lang=en