This is still unresolved (help from other people with Macs updating behind an MWG and strong egress rules still being solicited!), but I did learn several things:
1) MWG 188.8.131.52 doesn't appear to grok sites that use SSL SNI (server name identification). http://en.wikipedia.org/wiki/Server_Name_Indication
If you have access to a linux box or cygwin with a recent openssl ( > 1.0 ) have a look at
openssl s_client -showcerts -servername swscan.apple.com -connect swscan.apple.com:443
(which gives the appropriate swscan.apple.com certificate)
openssl s_client -showcerts -connect swscan.apple.com:443
(which coughs up the *.isu.apple.com wildcard certificate)
This difference is telling. MWG 184.108.40.206 appears to ship with openssl 0.9.8.x ... which doesn't grok SNI and its s_client lacks the -servername support. So methinks a lot of people who have a certificate verification rule in their policy will have to manually add a cert whitelist entry for swscan.apple.com to work through the difference between *.isu.apple.com and swscan.apple.com.
2) In addition to having to manually import swscan.apple.com's SSL cert, if you're controlling POST uploads in an environment, apparently Apple wants to upload things to:
[update: this may be a red herring -- the user with whom I was working admitting to having registered it with his personal Apple account which may have caused this communication to happen and may be unrelated to updates]
3) And if you're blocking personal storage networks, even if icloud isn't configured mountain lion appears to want to download from
But I still don't have this football in the endzone. For some reason I'm still getting blocks from keyvalueservice.icloud.com that I'm trying to clear.