Re: [Fed-Talk] [EXTERNAL] ATO for Notarization?
Re: [Fed-Talk] [EXTERNAL] ATO for Notarization?
- Subject: Re: [Fed-Talk] [EXTERNAL] ATO for Notarization?
- From: "Blumenthal, Uri - 0553 - MITLL via Fed-talk" <email@hidden>
- Date: Fri, 19 Jul 2019 20:12:16 +0000
- Thread-topic: [Fed-Talk] [EXTERNAL] ATO for Notarization?
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").
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