Support x509 certificate on iOS.

Support x509 certificate on iOS.

The iOS implementation uses both NSS and system API. This CL creates
x509_certificate_nss_util to allow iOS to share code with the NSS
implementation. The iOS specific code is in x509_certificate_ios.

BUG=145954
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157325

[droger, 2012-09-11 12:24:15]

Ryan Sleevi:
following our discussions, I applied your suggestions and put together a
Chromium CL.

[Ryan Sleevi, 2012-09-11 16:49:34]

On 2012/09/11 12:24:15, droger wrote:
> Ryan Sleevi:
> following our discussions, I applied your suggestions and put together a
> Chromium CL.

Sorry, any reason why x509_certificate_nss_util.h instead of just placing it
into x509_util_nss ?

[droger, 2012-09-11 17:26:34]

On 2012/09/11 16:49:34, Ryan Sleevi wrote:
> Sorry, any reason why x509_certificate_nss_util.h instead of just placing it
> into x509_util_nss ?

I think we can probably use x509_util_nss.
There is one place where x509_certificate_nss is excluded but x509_util_nss is
not (see my comment).
It may be a mistake though.

[droger, 2012-09-11 17:26:49]

https://chromiumcodereview.appspot.com/10928107/diff/10001/net/net.gyp
File net/net.gyp (right):

https://chromiumcodereview.appspot.com/10928107/diff/10001/net/net.gyp#newcod...
net/net.gyp:999: 'base/x509_certificate_nss_util.h',
x509_util_nss does not show here.

[Ryan Sleevi, 2012-09-11 18:39:27]

https://chromiumcodereview.appspot.com/10928107/diff/10001/net/net.gyp
File net/net.gyp (right):

https://chromiumcodereview.appspot.com/10928107/diff/10001/net/net.gyp#newcod...
net/net.gyp:999: 'base/x509_certificate_nss_util.h',
On 2012/09/11 17:26:49, droger wrote:
> x509_util_nss does not show here.

And that's ok.

The exclusion of these files is about excluding functionality specifically
related to NSS-managed trust. The proposed additions to x509_util_nss have
nothing to do with trust, and only with parsing certificates.

It won't cause any compile issues for Win/Mac, it's excluded for Android builds
on line 917/918, and it's needed for iOS.  It should be fine.

[droger, 2012-09-12 09:23:25]

Thanks for the comments.
Please take another look.

[Ryan Sleevi, 2012-09-12 19:34:44]

Thanks!

This LGTM as a faithful change, although I have a few nits related to comments,
and a request that you check the callsites for one of the functions just to be
extra-safe :)

I don't think anything mentioned requires a re-review however, so please feel
free to submit after addressing.

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_cert...
File net/base/x509_certificate_ios.cc (right):

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_cert...
net/base/x509_certificate_ios.cc:20: #include <vector>
nit: It is not immediately clear to me, based on
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Names_and_Orde...
, whether C and C++ headers should be in separate sections (eg: newline
separated) or together.

However, it does seem like <vector>, <CommonCrypto/CommonDigest.h>, and
<Security/Security.h> should appear before the NSS types, since the NSS types
(on iOS) fall under "4. Other libraries' .h files."

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_cert...
net/base/x509_certificate_ios.cc:44: // SecCertificateCreateFromData() does not
return any errors if called with
Turns out Apple fixed this in OS X 10.8, and I'd be willing to guess (but
haven't confirmed) iOS 6, based on the rate at which bugs are fixed between the
two.

That said, this comment is incorrect with respect to "an API that requires a
CSSM handle is called", since "CSSM" is not exposed (or, supposedly, implemented
- although the 10.8 sources suggest otherwise).

Perhaps

// Returns true if a given |cert_handle| is actually a valid
// X.509 certificate handle.
//
// SecCertificateCreateFromData() does not always force the
// immediate parsing of the certificate, and as such, may
// return a SecCertificateRef for an invalid/unparsable
// certificate. Force parsing to occur to ensure that the
// SecCertificateRef is correct. On later versions where
// SecCertificateCreateFromData() immediately parses, rather
// than lazily, this call is cheap, as the subject is cached.

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_cert...
net/base/x509_certificate_ios.cc:115: CFDataGetLength(a_data)) == 0;
As a follow-up, it would be good to test if lines 110-115 are actually
necessary. I seem to recall it was specific to working around an OS X 10.5 issue
where SecCertificateRef's did not have an appropriate type-specific CFEqual
function specified. This may have always been correct/fixed on iOS, at which
point, lines 110-115 never execute.

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_cert...
net/base/x509_certificate_ios.cc:167: DCHECK_NE(CFDataGetLength(cert_data), 0);
nit: DCHECK_NE(expected, actual)

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
File net/base/x509_util_ios.cc (right):

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
net/base/x509_util_ios.cc:70: return nss_cert_handle_;
nit: We'll want to ensure that all callers who call cert_handle() are checking
that it's valid (!= NULL). Whether that's done with an IsValid helper or a
direct NULL check, I'm ambivalent on, but it is possible that

- A Cert can be represented as a SecCertificateRef, but not a CERTCertificate*
- A Cert can be represented as a CERTCertificate*, but not a SecCertificateRef

Usually this comes down to date/time handling, but may also happen with
extensions.

Callers should never assume they're guaranteed to get a good result from a good
input, and because it represents "untrusted" (eg: network) input, they should
handle it gracefully (eg: don't DCHECK/CHECK/crash)

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
File net/base/x509_util_ios.h (right):

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
net/base/x509_util_ios.h:30: // use the NSS library to parse it.
nit: s/use/uses/

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
File net/base/x509_util_nss.cc (right):

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
net/base/x509_util_nss.cc:276: namespace net {
nit: Move this to line 28, and you can avoid having to specify the explicit
net:: calls (line 261, 265)

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
net/base/x509_util_nss.cc:352: DCHECK(arraysize(kOIDs) == arraysize(values));
nit: DCHECK_EQ

[droger, 2012-09-13 13:03:05]

I applied your comments, thanks.
I have not committed yet.

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_cert...
File net/base/x509_certificate_ios.cc (right):

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_cert...
net/base/x509_certificate_ios.cc:115: CFDataGetLength(a_data)) == 0;
On 2012/09/12 19:34:44, Ryan Sleevi wrote:
> As a follow-up, it would be good to test if lines 110-115 are actually
> necessary. I seem to recall it was specific to working around an OS X 10.5
issue
> where SecCertificateRef's did not have an appropriate type-specific CFEqual
> function specified. This may have always been correct/fixed on iOS, at which
> point, lines 110-115 never execute.

The unit tests pass if I simply return CFEqual(a, b) on line 108. Is this
enough?
Otherwise I could some kind of DCHECK, but we will need to remember removing it
later if it does not fire.

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
File net/base/x509_util_ios.cc (right):

https://chromiumcodereview.appspot.com/10928107/diff/12005/net/base/x509_util...
net/base/x509_util_ios.cc:70: return nss_cert_handle_;
On 2012/09/12 19:34:44, Ryan Sleevi wrote:
> nit: We'll want to ensure that all callers who call cert_handle() are checking
> that it's valid (!= NULL). Whether that's done with an IsValid helper or a
> direct NULL check, I'm ambivalent on, but it is possible that
> 
> - A Cert can be represented as a SecCertificateRef, but not a CERTCertificate*
> - A Cert can be represented as a CERTCertificate*, but not a SecCertificateRef
> 
> Usually this comes down to date/time handling, but may also happen with
> extensions.
> 
> Callers should never assume they're guaranteed to get a good result from a
good
> input, and because it represents "untrusted" (eg: network) input, they should
> handle it gracefully (eg: don't DCHECK/CHECK/crash)

I added special cases in GetSubjectAltName() and Initialize().
GetPublicKeyInfo already fails gracefully.

[commit-bot: I haz the power, 2012-09-14 08:31:10]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/droger@chromium.org/10928107/7014

[commit-bot: I haz the power, 2012-09-14 11:32:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/droger@chromium.org/10928107/7014

[commit-bot: I haz the power, 2012-09-14 17:46:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/droger@chromium.org/10928107/7014

[commit-bot: I haz the power, 2012-09-14 22:48:57]

Sorry for I got bad news for ya.
Compile failed with a clobber build.
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2012-09-17 08:09:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/droger@chromium.org/10928107/7014

[commit-bot: I haz the power, 2012-09-17 08:24:04]

Sorry for I got bad news for ya.
Compile failed with a clobber build.
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[droger, 2012-09-17 08:57:49]

It does not compile on win debug (win rel is fine though?), because of
unresolved externals in NSS:

_CERT_GetCountryName
_CERT_GetStateName
_CERT_GetLocalityName
_CERT_DecodeAVAValue
_CERT_GetAVATag
_DER_DecodeTimeChoice_Util
_CERT_GetNextGeneralName
_CERT_DecodeAltNameExtension
_CERT_DecodeCertPackage

Maybe because they need to be exported (added to
nss/mozilla/security/nss/exports_win.def) -- I'm not familiar with windows build
system.
Other options would be to move the code to another file excluded on windows, or
ifdef'ing.

[Ryan Sleevi, 2012-09-17 16:37:46]

On 2012/09/17 08:57:49, droger wrote:
> It does not compile on win debug (win rel is fine though?), because of
> unresolved externals in NSS:
> 
> _CERT_GetCountryName
> _CERT_GetStateName
> _CERT_GetLocalityName
> _CERT_DecodeAVAValue
> _CERT_GetAVATag
> _DER_DecodeTimeChoice_Util
> _CERT_GetNextGeneralName
> _CERT_DecodeAltNameExtension
> _CERT_DecodeCertPackage
> 
> Maybe because they need to be exported (added to
> nss/mozilla/security/nss/exports_win.def) -- I'm not familiar with windows
build
> system.
> Other options would be to move the code to another file excluded on windows,
or
> ifdef'ing.

Ah, right. Because even though it's not used, it's still compiled and linked.

#if defined(USE_NSS) || defined(OS_IOS)

would be better here.

[commit-bot: I haz the power, 2012-09-18 07:51:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/droger@chromium.org/10928107/35

[commit-bot: I haz the power, 2012-09-18 09:04:35]

Change committed as 157325