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.

[jessepeterson]

@hslatman picking this up way late, but philosophically I consider attaching things on the context to be suitable only for context-lived things that originate in and expire after the context is done (like trace IDs, connection identifiers, etc.). Anything that lives longer than a single context's lifetime I generally try to make part of the containing service/object.

To that end I'd probably move it out of the context if it's some sort of configuration or state that's meant to be shared across different contexts.

Hope that helps!

[hslatman]

Hey @jessepeterson, I have rebased the branch and changed the attestation CA to be passed similar to the DB now. It's been quite a while since doing this initially, and I noticed there's still some TODOs left from back then. I think most are for things that were unknown at the time and/or have changed since then. It'll need some more time to complete in full.

[jessepeterson]

@hslatman no worries. if you want to land 'something working' vs. a more fleshed out PR I'm just fine with that, too — this little project is quite hacky! :)