Post not yet marked as solved
Hi Quinn, did anything ever come out of this?
Post not yet marked as solved
Thanks again. Do you deem it worthwile to file an enhancement request asking for API parity in this regard (i.e. by providing an initializer on SecureEnclave.P256.Signing.PrivateKeythat takes a parameter akin to kSecAttrIsPermanent)?
Post not yet marked as solved
Ok, I think I am getting close. So while SE keys are not actually stored inside the Secure Enclave keys generated by the Security framework are (or can be, depending on whether kSecAttrIsPermanentis set or not) stored in the keychain. Keys generated by Apple CryptoKit are not stored at all and there is no way to convert between the two kinds of keys. Correct?
Post not yet marked as solved
Thanks Quinn! You know, there are days where I feel I would not get anything done without you helping me out...
Does that mean the dataRepresentation of a SecureEnclave.P256.Signing.PrivateKey is already stored in the keychain by the system, but is inaccessible to client code so the only way for it to get a reference to such a key is to store the dataRepresentation itself and recreate the key from it?
And if the key had instead been created by not using CryptoKit, but the Security framework (passing .privateKeyUsage in the access control list) it could later be retrieved by SecItemCopyMatching, correct?
Post not yet marked as solved
Why do you need this in nscurl specifically?
Mostly just to understand how specific status codes are handled on iOS.
To elaborate: I have been hitting the same issue described here and here - the URL Loading System raises an error if it receives a response with the status code 403 and a client certificate was involved in the handshake (regardless of whether the certificate was accepted or not). I (re-)raised this as FB10026351.
In my case all requests to the server require client authentication and the server may return 403 for unrelated reasons (e.g. for domain errors). The server team agreed to use a different status code for those cases but wanted me to make sure they don't pick one where a similar situation could arise. In my lab appointment the network engineer pointed out that there are in fact status codes other than 403 that receive special treatment and suggested using nscurl to quickly check how specific status codes are handled, but apparently the behaviour changes if a client certificate is involved. Here is what I found:
Without client authentication:
If no client certificate is involved and the server responds with 401 the client gets an error (NSURLErrorCannotConnectToHost)
If no client certificate is involved and the server responds with 403 the client gets the response
With client authentication:
If a (valid) client certificate is involved and the server responds with 401 the client gets the response
If a (valid) client certificate is involved and the server responds with 403 the client gets an error (NSURLErrorClientCertificateRequired)
However, the scenarios involving a client certificate cannot be tested with nscurl, hence my question.
Post not yet marked as solved
Thanks Quinn! The Random Unification - https://github.com/apple/swift-evolution/blob/master/proposals/0202-random-unification.md Swift evolution proposal makes the same assumption. Without a definitive source one could also assume that arc4random always utilizes RC4 and conclude that it (and thus the Swift SystemRandomNumberGenerator - https://developer.apple.com/documentation/swift/systemrandomnumbergenerator) is to be avoided, though.
For the record: It seems that the problem was caused by xcodebuild not waiting for the pre-action script to complete before proceeding with the build. In that case the entitlements file was not present at the location pointed to by CODE_SIGN_ENTITLEMENTS (it is in fact not under version control there, it is instead copied there by the pre-action script and being gitignored afterwards). A reboot of the Jenkins node was enough to remedy the problem - at least for the time being. The CSSM errors mentioned above seem to be unrelated after all.
I have been watching the logs closely during on of the failing builds and I see codesign report a "UNIX error exception: 17" (EEXIST maybe?) followed by several CSSM errors (e.g. CSSMERR_DL_DATASTORE_DOESNOT_EXIST) before xcodebuild reports a "UNIX error exception: 22" (EINVAL?). Does that ring any bells?
Oh well... This does indeed work. The remark "You must import this API explicitly." completely threw me off. Thanks Quinn!
Thanks for the updates, Quinn!
FWIW, I opened a TSI (#709328399) to investigate this.
Hi Quinn, I assume you are referring to this sentence of said support article:"Publicly trusted Transport Layer Security (TLS) server authentication certificates issued after October 15, 2018 must meet Apple's Certificate Transparency (CT) policy to be evaluated as trusted on Apple platforms."Does that mean that we don't have to require CT at all anymore?
Thanks Quinn, I may file a DTS incident to have this addressed in greater depth.However, I have one more - somewhat related - question: As far as I can tell there is no way to require CT for _all_ network connections since the corresponding Info.plist key can only be added inside an exception dictionary - or is it possible to specify an ATS exception providing a wildcard for the <domain-name-string>, e.g. '*' (apparently it is not possible to add NSRequiresCertrificateTransparency as a primary key)?Regards,Jochen
Post not yet marked as solved
I ran into the same issue, however in my case I didn't pass .privateKeyUsage when creating the ACL and was using .createItem when evaluating it.As it turns out the sample code exhibits the same behaviour if built with Xcode 9.3 and run on an iOS 11.3 Simulator: The "Add item (TouchID and password)" test returns the exact same error you described. The README.md, however, states "This sample does not support the simulator.".As a matter of fact I still can't quite get my head around what evaluateAccessControl:operation:localizedReason:reply: is actually useful for.
Post not yet marked as solved
I tried to find authoritative information since when HSTS is supported on iOS but failed. Could this be since iOS 11?
