Proposal: Extend Windows KeyStore support to include access to the local machine location

Mon Apr 11 19:02:59 UTC 2022

Hello,

if you can open/target specific stores dynamically it is up to the developer/user what they do with it (very similar to keystore files). Addressbook in my post was only an example (but a good one: imagine Java app wants to import the addressbook entries)

Gruss
Bernd
--
https://bernd.eckenfels.net
________________________________
From: Wei-Jun Wang <weijun.wang at oracle.com>
Sent: Monday, April 11, 2022 8:45:12 PM
To: Mat Carter <Matthew.Carter at microsoft.com>
Cc: Bernd Eckenfels <ecki at zusammenkunft.net>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location

Sorry for the late reply.

Yes, your suggestions are good. We can support "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE".

For read-only access to the keystores, we have already allowed writing and this probably will not change. If we do want to support read-only later, it could be a new name or a different LoadStoreParameters.

As for Bernd's suggestion. Maybe DomainKeyStore can be used to combine existing keystores. I dare not add ADDRESSBOOK at the moment. Are certificates inside it fully trusted? Or you need to build a certpath to one of the root CAs to trust any of them?

Thanks,
Weijun

> On Apr 11, 2022, at 2:06 PM, Mat Carter <Matthew.Carter at microsoft.com> wrote:
>
> Hi Weijun
>
> Did my answers address your concerns?  Also do you have an opinion on Bernd's suggestion?
>
> Thanks in advance
> Mat
>
> Sent from Outlook
> From: security-dev <security-dev-retn at openjdk.java.net> on behalf of Bernd Eckenfels <ecki at zusammenkunft.net>
> Sent: Tuesday, April 5, 2022 11:20 AM
> To: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
>
> BTW, since this is Windows specific anyway and since we have also a combining virtual Keystore, why not allow a new naming scheme which allows to access any of the Keystores? like “Windows-ROOT/ADdressbook”?
>
> Gruss
> Bernd
>
> --
> http://bernd.eckenfels.net
> Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Mat Carter <Matthew.Carter at microsoft.com>
> Gesendet: Dienstag, April 5, 2022 5:22 PM
> An: Wei-Jun Wang <weijun.wang at oracle.com>
> Cc: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
>
> Hi Weijun
>
> Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1
>
> >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear
> >> there and automatically chosen by a key manager.
> >>
> >> It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including
> >> new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE.
>
> I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing.  Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and
> "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both.
>
> I think this addresses point 1 also, but if not then I have a follow on question:
>
> >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is
> >> trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up.
>
> Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code.
>
> Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)?
>
> While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security)
>
> Thanks in advance
> Mat
>
> Sent from Outlook
>
>
> From: Wei-Jun Wang <weijun.wang at oracle.com>
> Sent: Friday, April 1, 2022 3:15 PM
> To: Mat Carter <Matthew.Carter at microsoft.com>
> Cc: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
>
> Hi Mat,
>
> We have 2 main concerns:
>
> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up.
>
> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager.
>
> It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE.
>
> And we have no plan to add other types like ADDRESSBOOK.
>
> Thanks,
> Weijun
>
> > On Mar 31, 2022, at 5:16 PM, Mat Carter <Matthew.Carter at microsoft.com> wrote:
> >
> > Current support for KeyStores on Windows is limited to the current user location [1]
> >
> > There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5]
> >
> > Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API.
> >
> > Given the above I propose that we add native support for local machine KeyStore locations
> >
> > Users can currently access two physical key stores (in the current user location):
> >
> > "Windows-MY": .Default
> > "Windows-ROOT": .Default.LocalMachine, .SmartCard
> >
> > Adding the local machine location opens up access to a further two physical key stores …
> >
> > "Windows-MY": .Default
> > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard
> >
> > Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject
> >
> > Thanks in advance
> > Mat Carter
> >
> > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fseccrypto%2Fsystem-store-locations&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hWj0cEVRachk47aqIKJYIwiaqTcACjWGn38AzmutX9I%3D&reserved=0
> > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TdXrBjrjqPniADcJiFnwQfi5uaCnI9BzgCPPJe%2FAhGA%3D&reserved=0
> > [3] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fsecurity-dev%2F2018-August%2F017832.html&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O4hI%2BTje%2FjtJTWosTLSNzVlQUW8s%2BoeoWMA27EaAHUc%3D&reserved=0
> > [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F70200603%2Faccessing-windows-local-machine-certificates-from-a-windows-service-written-in-j&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FNqqbV%2BIircmaoas%2F%2BUX%2F%2BQpWVq9fpoV%2F4lCNB77ZzE%3D&reserved=0
> > [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F3612962%2Faccess-local-machine-certificate-store-in-java&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JiEifjvBN%2B8ahoft9xdJhLwy1DEjkAWLHIVB1Oojnsk%3D&reserved=0
> >
> >
> > Sent from Outlook

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220411/2a3d72aa/attachment.htm>