Hi, We have a multi-platform application that requires integrity attestation before the backend will enable supporting services (fairly common scenario). I've read the documentation for DeviceCheck and AppAttest, as well as SafetyNet on the Android side. The Android documentation includes lots of examples of use, including server-side (though oddly in C# and Javascript... which I don't see as being server-side languages, but... oh, well). Anyway, maybe there's a server-side example of using an application attestation on the server when validating a client, as well as validating individual requests with assertions, but I've not been able to find it. It seems like a relatively important bit of functionality to ensure that apps aren't being compromised, while at the same time requiring a correct implementation... Why not give a reference implementation as a starting point to make sure developers are on the right path? Can anyone point me at an example as a Gist, etc? Thanks.

Hi, I was looking through our MTA logs and I noticed that the MacOS client sends: HELO smtpclient.apple when it should be sending: HELO my.fq.dn or if it has no meaningful mapping to a domain name, at least: HELO [192.168.1.19] Per RFC-2821: 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command. This seems pretty straightforward; why is the standard not being followed? Just double-checked: the iOS client does the same. If they all send the same meaningless string, this makes reading logs that much harder. Should be trivial to fix. Thunderbird had a similar bug, but I fixed that 15 years ago. Why diverge from the standards? SMTP is one of the easier RFC's to implement. Thanks, -Philip

I'm looking at a development attestation for an app we're developing in-house, and there's a couple of undocumented PEN's being used: Certificate:     Data:         Version: 3 (0x2)         Serial Number: 1631564652467 (0x17be0d4dfb3)         Signature Algorithm: ecdsa-with-SHA256         Issuer: CN = Apple App Attestation CA 1, O = Apple Inc., ST = California         Validity             Not Before: Sep 12 20:24:12 2021 GMT             Not After : Sep 15 20:24:12 2021 GMT         Subject: CN = a203e1588ab36ae2ffc362491c2948df5d03f3ed048d0c58a59c9e085724353c, OU = AAA Certification, O = Apple Inc., ST = California         Subject Public Key Info:             Public Key Algorithm: id-ecPublicKey                 Public-Key: (256 bit)                 pub:                     04:09:1a:ae:9f:d2:0b:89:e6:6b:ab:68:3e:70:e1:                     6d:0f:b1:2f:8b:4b:bd:c9:d2:54:ec:15:2c:b4:fc:                     4c:8d:fb:e1:49:0d:90:34:80:10:82:08:6c:49:58:                     7e:2c:5b:90:2b:80:2d:1f:f3:e9:36:59:51:d2:3e:                     1d:d2:f8:75:e3                 ASN1 OID: prime256v1                 NIST CURVE: P-256         X509v3 extensions:             X509v3 Basic Constraints: critical                 CA:FALSE             X509v3 Key Usage: critical                 Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment             1.2.840.113635.100.8.5:      0:d=0  hl=2 l= 111 cons: SEQUENCE               2:d=1  hl=2 l=   3 cons:  cont [ 4 ]             4:d=2  hl=2 l=   1 prim:   INTEGER           :0A     7:d=1  hl=4 l=   3 cons:  cont [ 1200 ]         11:d=2  hl=2 l=   1 prim:   INTEGER           :01    14:d=1  hl=4 l=   3 cons:  cont [ 1201 ]         18:d=2  hl=2 l=   1 prim:   INTEGER           :00    21:d=1  hl=4 l=   3 cons:  cont [ 1202 ]         25:d=2  hl=2 l=   1 prim:   INTEGER           :01    28:d=1  hl=4 l=   3 cons:  cont [ 1203 ]         32:d=2  hl=2 l=   1 prim:   INTEGER           :01    35:d=1  hl=4 l=  38 cons:  cont [ 1204 ]         39:d=2  hl=2 l=  36 prim:   OCTET STRING      :XKXEK7P8ZU.com.truepic.appattestdemo    77:d=1  hl=2 l=   6 cons:  cont [ 5 ]            79:d=2  hl=2 l=   4 prim:   OCTET STRING      :sks     85:d=1  hl=4 l=   3 cons:  cont [ 1206 ]         89:d=2  hl=2 l=   1 prim:   INTEGER           :05    92:d=1  hl=4 l=   3 cons:  cont [ 1207 ]         96:d=2  hl=2 l=   1 prim:   INTEGER           :00    99:d=1  hl=4 l=   3 cons:  cont [ 1209 ]        103:d=2  hl=2 l=   1 prim:   INTEGER           :00   106:d=1  hl=4 l=   3 cons:  cont [ 1210 ]        110:d=2  hl=2 l=   1 prim:   INTEGER           :00             1.2.840.113635.100.8.7:      0:d=0  hl=2 l=   6 cons: SEQUENCE               2:d=1  hl=4 l=   2 cons:  cont [ 1400 ]          6:d=2  hl=2 l=   0 prim:   OCTET STRING                   1.2.840.113635.100.8.2:      0:d=0  hl=2 l=  36 cons: SEQUENCE               2:d=1  hl=2 l=  34 cons:  cont [ 1 ]             4:d=2  hl=2 l=  32 prim:   OCTET STRING             0000 - 52 93 c9 c6 69 4e 74 3c-63 13 4b d0 0a 92 12 87   R...iNt<c.K.....       0010 - 36 64 cf c3 3d 8d c0 5b-3b 26 72 5a a4 5a ab 71   6d..=..[;&rZ.Z.q     Signature Algorithm: ecdsa-with-SHA256          30:65:02:31:00:d0:40:c9:18:68:10:c7:0d:2a:04:31:9a:38:          74:7a:ee:1e:a3:da:a3:58:05:0f:15:ae:86:9e:19:07:b8:d3:          67:fc:c1:3f:e4:c2:eb:1b:37:d5:b1:c3:6f:df:52:da:c0:02:          30:5b:8e:d8:67:9e:5d:59:64:68:bf:85:a8:a7:ae:e8:a8:e4:          06:f0:df:75:c5:e8:7e:0a:d4:24:64:e8:6c:c3:2d:ac:31:bf:          3f:d1:78:a7:00:ff:11:31:1b:28:08:27:5d .2 I get. It's documented in Validating Apps That Connect to Your Server. Some GitHub gists suggest that .7 is supposed to be an Octet String containing the iOS version number, but it's empty in our case. Unclear why. No idea what .5 is supposed to be. Does anyone have any insight into these last two? Also, how does one determine the particular that's generating the attestation? Android SafetyNet attestation generates a unique hash (as the list of SHA256's in apkCertificateDigestSha256); it seems to me that we might want to further fine-tune the handling of sensitive operations based on the specifics of the version. Lastly, the above cited documentation states, in the "Store the Public Key and Receipt" section: Store the verified public key from credCert on your server and associate it with the user for the specific device. You use this key to check assertions later. But iOS (and iPadOS) doesn't support multiple accounts per device. So I'm interpreting this to not refer to an associated AppleID, but rather credentials in some app-specific space defined by the app developer. Is that correct? Thanks