Device attestation #977
Device attestation #977
Conversation
|
|
github-actions
bot
added
the
needs triage
|
It's possible to test this by installing a profile with the root certificate, it can be done by visiting the roots.pem endpoint (https://ca.local/roots.pem) and then installing the ACMECertificate profile (acme.mobileconfig) using the Apple Configurator app: <?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>PayloadVersion</key>
<integer>1</integer>
<key>PayloadUUID</key>
<string>Ignored</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadDisplayName</key>
<string>ACME</string>
<key>PayloadIdentifier</key>
<string>com.example.myprofile</string>
<key>PayloadContent</key>
<array>
<dict>
<key>ClientIdentifier</key>
<string>YOUR DEVICE UDID OR SERIAL NUMBER</string>
<key>ExtendedKeyUsage</key>
<array>
<string>1.3.6.1.5.5.7.3.2</string>
</array>
<key>HardwareBound</key>
<true/>
<key>Attest</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.example.myacmepayload</string>
<key>PayloadType</key>
<string>com.apple.security.acme</string>
<key>PayloadUUID</key>
<string>cbdc6238-feec-4171-878d-34e576bbb813</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>Subject</key>
<array>
<array>
<array>
<string>C</string>
<string>US</string>
</array>
</array>
<array>
<array>
<string>O</string>
<string>Example Inc.</string>
</array>
</array>
<array>
<array>
<string>1.2.840.113635.100.6.99999.99999</string>
<string>test custom OID value</string>
</array>
</array>
</array>
<key>SubjectAltName</key>
<dict>
<key>dNSName</key>
<string>site.example.com</string>
<key>ntPrincipalName</key>
<string>site.example.com</string>
</dict>
<key>DirectoryURL</key>
<string>https://ca.local/acme/acme/directory</string>
</dict>
</array>
</dict>
</plist>The |
The attestation certificate contains the nonce as raw bytes in the extension 1.2.840.113635.100.8.11.1
With non standard SANs this will generate the SAN and provisioner extension in the same order.
This reverts commit 09b9673.
This new method will be used to validate to validate the device attestation payload.
The method storeError returns a nil error
On the step format, validate proof of possession of the private key validating the signature in the attestation statement.
|
@hslatman I think it is a good idea to start merging this; it will make it easy to improve on it. For example, to add tests on the new methods it will be nice to merge the attestation roots part too and use |
authority/provisioner/acme.go
Outdated
| // AuthorizeChallenge checks if the given challenge is enabled. By default | ||
| // http-01, dns-01 and tls-alpn-01 are enabled, to disable any of them the | ||
| // Challenge provisioner property should have at least one element. | ||
| func (p *ACME) AuthorizeChallenge(ctx context.Context, challenge string) error { |
There was a problem hiding this comment.
I think that for this specific function we don't necessarily need to be consistent with function names or arguments that exist in other provisioners. The ACME one is already somewhat different than the others, anyway. IsChallengeEnabled is a more logical name for this function, imo. I think the challenge can also be more strongly typed instead of using the string.
There was a problem hiding this comment.
The strongly typed thing is 59c5219.
I noticed custom methods in acme are using Authorize* form (AuthorizeOrderIdentifier).
There was a problem hiding this comment.
Renamed with fd4e96d
Description
Support for ACME device-attest-01 challenge. See:
We need to add SAN support for permanent identifiers in
go.step.sm/crypto. There's some work by @brandonweeks here. We can get rid of github.com/google/go-attestation dependency by encoding the SANs manually, extending the new SANs of smallstep/crypto#27