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.w...@oracle.com> Sent: Monday, April 11, 2022 8:45:12 PM To: Mat Carter <matthew.car...@microsoft.com> Cc: Bernd Eckenfels <e...@zusammenkunft.net>; security-dev@openjdk.java.net <security-dev@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.car...@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-r...@openjdk.java.net> on behalf of Bernd > Eckenfels <e...@zusammenkunft.net> > Sent: Tuesday, April 5, 2022 11:20 AM > To: security-dev@openjdk.java.net <security-dev@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-r...@openjdk.java.net> im Auftrag von Mat > Carter <matthew.car...@microsoft.com> > Gesendet: Dienstag, April 5, 2022 5:22 PM > An: Wei-Jun Wang <weijun.w...@oracle.com> > Cc: security-dev@openjdk.java.net <security-dev@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.w...@oracle.com> > Sent: Friday, April 1, 2022 3:15 PM > To: Mat Carter <matthew.car...@microsoft.com> > Cc: security-dev@openjdk.java.net <security-dev@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.car...@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
