Exercise 1: Why a Provisioning Profile Embeds Only the Public Key — Possible Solution
==========================================================================================

A certificate is built on a real public/private key pair, and the two
halves have genuinely different jobs. The private key is what actually
signs the app binary - it's the real, secret proof that a specific,
known developer or team produced this exact build. The public key's
job is the opposite: it lets anyone holding it - in this case, iOS
itself - verify that a signature really was produced by the matching
private key, without ever needing to know the private key itself.

A provisioning profile embeds only the public key precisely because
that's all iOS actually needs to do its job: check "was this app
signed by the identity this profile says it should have been?" That
check can be done completely using only the public key. The private
key never needs to travel anywhere - it stays exactly where it was
created, in Keychain on the signing Mac.

If the private key were embedded in the provisioning profile instead,
the profile itself - a real file that gets copied onto every device
the app is installed on, and often passed around during ad hoc
testing - would effectively become a live signing key in the hands of
anyone who received it. Any beta tester with a copy of the profile
could extract the private key and use it to sign an entirely different
binary as if it had come from the real developer, completely
defeating the entire point of code signing.

ANSWER: The provisioning profile embeds only the public key because
verifying a signature only requires the public key - the private key
is what actually creates the signature and must stay secret. Embedding
the private key instead would let anyone who ever received a copy of
the profile (including every beta tester) extract it and sign
fraudulent builds under the real developer's own identity.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the real asymmetric-key reasoning (signing needs the
private key, verifying only needs the public key) and gives a concrete
consequence of getting it backwards, rather than just restating which
key goes where.