Re: [Fed-Talk] [EXTERNAL] ATO for Notarization?
Re: [Fed-Talk] [EXTERNAL] ATO for Notarization?
- Subject: Re: [Fed-Talk] [EXTERNAL] ATO for Notarization?
- From: Chris Stone via Fed-talk <email@hidden>
- Date: Sat, 20 Jul 2019 14:47:47 +0000
- Thread-topic: [Fed-Talk] [EXTERNAL] ATO for Notarization?
Uri,
In the, What's new in Managing Apple Devices WWDC presentation, at around
28:50, the whitelisting of apps from notarization is mentioned. That
corresponds to slide 59 in the PDF deck.
Chris Stone
Apple Inc
410-245-7543
> On Jul 19, 2019, at 16:12, Blumenthal, Uri - 0553 - MITLL via Fed-talk
> <email@hidden> wrote:
>
> On 7/19/19, 2:44 PM, "Fed-talk on behalf of Jonathan Hess via Fed-talk"
> <fed-talk-bounces+uri=email@hidden on behalf of
> email@hidden> wrote:
>
>> Ya, analogies often have issues. So lets skip the analogy.
>
> :-)
>
>> Here is my question:
>>
>> Assume a US government entity actually has Apple hardware on a classified
>> network.
>> Now assume a contractor makes a classified app for Apple Hardware for some
>> US government
>> entity. Will that application work on Apple hardware on any appropriate
>> government classified network?
>>
>> If the answer is yes because it gets notarized, then the next question is
>> how is it going to get
>> notarized -- the contractor can not send the app to Apple.
>
> Exactly.
>
>> If the answer is yes because it is in the same "enterprise," how is that? A
>> contractor developer
>> signing of the app would be for the "contractor" enterprise -- this is not
>> the same as the "government"
>> enterprise or enterprises.
>
> And how would the notion of "enterprise" be translated to "notarization"?
> E.g., with digital signatures, I define what Root CAs I trust. But with
> notary...?
>
>> Some contractors may provide source for the governement to compile and sign
>> (with a developer cert)
>> but some may not.
>>
>> So... how is this suppose to work?
>
> I personally think that it CANNOT work (unless you can disable it - at which
> point the question becomes "how much of existing security would I have to
> ditch to get past this st**id notarizer?"), and the whole idea is the
> opposite of smart.
>
> See below.
>
>> On Jul 19, 2019, at 10:39 AM, Ken Hornstein via Fed-talk
>> <email@hidden> wrote:
>> As I understand it the notarization service gets the binary application
>
> Stop right there. Why would an organization allow its developers to share
> their binaries with an external "notarization service"? Would yours...?
> (If in doubt - talk to your boss, and see how s/he reacts. ;)
>
> But there are counter-examples: some vendors wanted to sell cloud-based
> antivirus solutions, and were quickly shown the door. ;)
>
>> ... It wouldn't
>> surprise me at all if Apple kept a copy of the binary around ...
>
> Funny, how great minds think alike. Apple just might hold on to my binary...
> Why am I not thrilled? More important - why aren't my bosses going to be
> thrilled?
>
>> if you distribute your application on a public website
>> then Apple's not getting anything that's not available to the entire
>> Internet.
>
> That is correct.
> And for this kind of public apps the right solution would be "notarizing" the
> app when it hits Apple App Store, not "in advance". Though note that unless
> this app is explicitly sent to the App Store by its developer - the whole
> process sounds like "invasion of privacy".
>
> Regardless, we aren't doing this kind of distribution/deployment. Anybody at
> DoD (or other government agency) cares to correct me here?
>
>> If you distribute your application within a smaller community,
>> such as your enterprise or to only a few users then I can understand
>> why you might have a concern on what Apple is doing with your application,
>
> Good! We're getting somewhere.
>
>> but again, all they're getting is the same application binary that is
>> shared within your user community.
>
> Apple and its "notarizing service" are not members of the privileged group
> named "my user community". So - surprise! - they are NOT getting a copy.
>
> I personally think that Apple's position in corporate and government
> organization is precarious enough as is - and it would be extremely non-smart
> for Apple to drive a stake through its own heart by forcing the leadership to
> summarily proscribe these platforms from our enterprises (which I don't doubt
> they'd do if they start thinking that "any the code we compile gets sent to
> Apple").
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Fed-talk mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden