Add ACMECertificate payload handling with Device Attestation

[hslatman]

This adds support for handling the ACMECertificate payload.

Currently always requires configuration for the (fake) attestation CA to be supplied:

$ ./mdmb -uuids 2678F47F-7A0B-4E7E-BEBC-29C1DCAF28C6 devices-profiles-install -f acme-da.mobileconfig -cert attca.crt -key attca_key -pass password
...
$ ./mdmb -uuids all devices-profiles-list
profiles for UUID: 2678F47F-7A0B-4E7E-BEBC-29C1DCAF28C6
com.smallstep.acmedademo

Example ACMECertificate configuration, with attestation enabled (dropdown):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	<dict>
		<key>PayloadContent</key>
		<array>
			<dict>
				<key>Attest</key>
				<true/>
				<key>ClientIdentifier</key>
				<string>2678F47F-7A0B-4E7E-BEBC-29C1DCAF28C6</string>
				<key>DirectoryURL</key>
				<string>https://127.0.0.1:8443/acme/appleacmesim/directory</string>
				<key>ExtendedKeyUsage</key>
				<array>
					<string>1.3.6.1.5.5.7.3.2</string>
				</array>
				<key>HardwareBound</key>
				<true/>
				<key>KeySize</key>
				<integer>384</integer>
				<key>KeyType</key>
				<string>ECSECPrimeRandom</string>
				<key>KeyUsage</key>
				<integer>5</integer>
				<key>PayloadIdentifier</key>
				<string>com.apple.security.acme.cbdc6238-feec-4171-8784-98e576bbb814</string>
				<key>PayloadType</key>
				<string>com.apple.security.acme</string>
				<key>PayloadUUID</key>
				<string>cbdc6238-feec-4171-8784-98e576bbb814</string>
				<key>PayloadVersion</key>
				<integer>1</integer>
				<key>Subject</key>
				<array>
					<array>
						<array>
							<string>C</string>
							<string>NL</string>
						</array>
					</array>
					<array>
						<array>
							<string>O</string>
							<string>Smallstep ACME DA Demo</string>
						</array>
					</array>
				</array>
			</dict>
		</array>
		<key>PayloadDisplayName</key>
		<string>ACME DA Certificate</string>
		<key>PayloadIdentifier</key>
		<string>com.smallstep.acmedademo</string>
		<key>PayloadType</key>
		<string>Configuration</string>
		<key>PayloadUUID</key>
		<string>734EEACF-1334-4B65-8E8C-6AC07E9B79E5</string>
		<key>PayloadVersion</key>
		<integer>1</integer>
	</dict>
</plist>

The example ACMECertificate payload is configured to connect to a step-ca instance. Its configuration should be similar to what's described in hslatman/ios-acme-simulator.

Changes in jessepeterson/cfgprofiles#2 need to be merged first for the com.apple.security.acme payload type to be recognized.

In its current state, some ACME flow details will be logged. I can remove that if requested, or change it so that log output is only shown when requested. I noticed #1, so maybe that needs to be taken into account for that.

The (fake) attestation CA configuration is currently always required when trying the ACMECertificate payload, because there's no other way for the Apple ACME client to prove control over ACME identifiers. @jessepeterson Configuration of the (fake) attestation CA is done through flags (without fallback). They're only required for the ACMECertificate payload and the (fake) attestation CA is injected through a context.Context. Are you OK with that approach, or would you like it to be passed around as a property of Device (similar to the DB instance) instead? I noticed #2, for which I think the context approach might help to a certain extent.

[jessepeterson]

@hslatman bump :)

[hslatman]

Oh wow, totally forgot about this one 😅

Are you OK with the things mentioned in the last paragraph, @jessepeterson? An alternative to having to provide the attestation CA is to generate and persist one, but that would require informing the user about where the root CA certificate is stored, as that's needed for attestation certificate validation.