You're operating under the misapprehension that PKs are tied to ESPs; they aren't. The Secure Boot cryptographic features require that individual boot loader files be signed, but those files are stored on ordinary FAT filesystems that are themselves not signed, encrypted, or otherwise cryptographically interesting. A signed boot loader file can be moved from one partition to another and continue to work just fine, at least from a Secure Boot perspective. (Moving such a file may cause it to fail because it's been separated from critical configuration files or the like, of course, but that's another matter.)
To more directly answer the question, the EFI specification imposes no limit on the number of ESPs that may be present on a computer or on a hard disk; you could have dozens of them if you wanted to, and that would be fine from the EFI's perspective. Unfortunately, Microsoft is not so flexible; Windows officially supports just one ESP per disk (maybe per computer; I'm a bit foggy on that detail). I don't know about Windows 8, but the Windows 7 installer will flake out if it sees more than one ESP on a disk; the installation will proceed part of the way and then fail. (At least, that's what it's done in my tests.) That said, if you create a second ESP after installing Windows, Windows will continue to boot and operate correctly, at least as far as I've seen. (I can't promise that it won't misbehave if you use some particular feature, though.)
Overall, then, in a multi-boot environment, I recommend restricting yourself to one ESP. I also recommend making it rather large -- 550MiB is my usual recommendation, for assorted technical reasons having to do with rare bugs and FAT sizes. That said, if you've got an existing installation with a smaller ESP, it's probably fine to just stick with it. In either case, Linux and Windows can share a single ESP just fine. I do, however, recommend backing it up early and often -- definitely back it up before installing a new OS. Because the ESP holds your boot loaders, an accidental erasure of it will render your computer unbootable.
First, you don't set the mount point in GParted; that's done manually (and temporarily) via the mount command or permanently by editing /etc/fstab. Thus, your concern over this issue is misplaced.
Second, an EFI System Partition (ESP) is simply a FAT partition with a particular type code (namely, C12A7328-F81F-11D2-BA4B-00A0C93EC93B on GPT disks) set. Note that the mount point in /etc/fstab is not part of the ESP's definition; it's just conventional (but not required) in Linux to access the ESP by mounting it at /boot/efi, typically via an /etc/fstab entry. How you set the type code varies from one program to another:
- In
gdisk, you set the type code to EF00. (gdisk uses two-byte type codes that expand out to the real type codes on the disk; "EF00" is just a mnemonic for "C12A7328-F81F-11D2-BA4B-00A0C93EC93B".)
- In GParted or
parted, you set the "boot flag." Note, however, that this works only on GPT disks; you cannot set the ESP type code on MBR disks with these programs. (This isn't normally a big deal, since EFI-based computers usually boot from GPT disks.)
- In the Ubuntu installer, you identify the partition as an "EFI boot partition." It then sets the type code and will set up
/etc/fstab appropriately.
- In recent versions of Linux
fdisk, you set the partition type by its number (1 for "EFI System" on GPT disks or 0xEF on MBR disks) or by entering the full type code on GPT disks.
Third, the ESP does not hold firmware -- firmware is, by definition, stored in chips on the motherboard. Thus, your effort to install the EFI firmware on the ESP is a wild goose chase. (There are two exceptions to this rule. First, you might store a firmware file on the ESP in order to update the firmware on your computer. This is just a temporary holding area, though. Second, the DUET or Clover boot loader, the EFI is loaded as a regular program, typically from the ESP. These tools are BIOS boot loaders, though, that enable BIOS-only computers to boot as if they were EFI machines; they are not normally used on computers with EFI firmware, which you claim your computer has. Technically, neither DUET nor Clover is firmware; they're BIOS boot loaders that do the same job as EFI.)
Finally, I can think of a number of possible causes for your problem, but without further information, I'd need to write half a book to cover them all. I recommend you run the Boot Info Script on the computer. This will produce a file called RESULTS.txt. Post it to a pastebin site and post back with the URL to your document. That will give hard data on your configuration, which will greatly reduce the range of possible causes of your problem.
Best Answer
This question is among the top results on Google for "How to resize the EFI System Partition" (unsurprising, given that's the question title), however the current answers here, though containing good advice for the OP's situation and generally useful information, do not actually attempt to answer that question as stated. My previous rather terse (now deleted) attempt to answer that question was downvoted, so here's a more thorough one.
There's a good chance that you're reading this because you've tried the obvious thing (use gparted) and got the error "GNU Parted cannot resize this partition to this size. We're working on it!". You may have also tried doing it from within Windows (using Disk Management), only to discover that Windows refuses to perform any operations with the ESP at all.
Well, the next best thing to actually resizing the partition is to recreate it. Here are the detailed steps for doing this:
If you are resizing the ESP of the disk you're booting on, ensure you have some bootable rescue media on hand that you can use to repair your system in case things go wrong. Having a backup of your data before doing any disk partitioning operations is a good idea in general.
If you are enlarging the ESP, make room by moving or resizing any partitions directly following it, using your favorite partitioning tool (e.g. gparted).
Mount the ESP, if it's not mounted already:
Make a backup of its contents:
Unmount the ESP:
Delete and recreate the ESP:
Format the ESP:
Restore the ESP's contents:
Update EFI entry in /etc/fstab
That should be everything. I've successfully used the above procedure to resize the ESP for a Windows installation whose ESP was too small (50 MB) to allow Windows to upgrade to Fall Creators' Update (before resizing the ESP, Windows Update failed with error 0x8E5E03FB, and the Update Assistant with error 0xc1900200).