Resolve certificate references in ONC by PEM.

chromeos/test/data/network/managed_toplevel1_with_cert_pems.onc

Index: chromeos/test/data/network/managed_toplevel1_with_cert_pems.onc
diff --git a/chromeos/test/data/network/managed_toplevel1.onc b/chromeos/test/data/network/managed_toplevel1_with_cert_pems.onc
similarity index 98%
copy from chromeos/test/data/network/managed_toplevel1.onc
copy to chromeos/test/data/network/managed_toplevel1_with_cert_pems.onc
index 1f0d1272d6727fd3e3ec3eb0f6f13783e9420142..43332973d78249ba50afd72441600e8aefd60492 100644
--- a/chromeos/test/data/network/managed_toplevel1.onc
+++ b/chromeos/test/data/network/managed_toplevel1_with_cert_pems.onc
@@ -18,7 +18,7 @@
               "Recommended": [ "Username", "Password" ],
               "ClientCertType": "Pattern",
               "ClientCertPattern": {
-                  "IssuerCARef": [ "openvpn-test-ca" ],
+                  "IssuerCAPEMs": [ "pem1" ],

[Mattias Nissler (ping if slow), 2013/07/02 13:00:35]

so we're now inlining the PEMs? I don't think that's a good idea on the ONC
format side of things.

[pneubeck (no reviews), 2013/07/02 14:38:43]

This file is used for testing NetworkLibrary::LoadOncNetworks, which expects an
ONC in which GUID references are replaced by PEMs.

We continue to support GUID references from the policy sever.
The PEMs are meant to be used internally in Chrome. However, a side-effect of
this CL is that we also support PEMs in the policy ONC.

[Mattias Nissler (ping if slow), 2013/07/02 15:34:06]

OK, all good if the existing GUID-based ONC stuff continues working. I suspect
we don't even want to change the spec to avoid people getting the impression
inline PEMs are the new hotness.

                   "Recommended": [ "EnrollmentURI", "IssuerCARef" ]
               }
           },