Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
No problem. The code change looks fine to me but you will need to create a CSR. I'll add a comment in the PR. Thanks, Weijun > On Apr 12, 2022, at 5:37 PM, Mat Carter wrote: > > Weijun > > Here's a PR [1] if you would like to review and consider sponsoring > > [1] https://github.com/openjdk/jdk/pull/8211 > > > Cheers > Mat > > Sent from Outlook > From: Wei-Jun Wang > Sent: Monday, April 11, 2022 3:33 PM > To: Mat Carter > Cc: Bernd Eckenfels ; security-dev@openjdk.java.net > > Subject: Re: Proposal: Extend Windows KeyStore support to include access to > the local machine location > > Added a comment and assigned the enhancement to you. Thanks. > > --Weijun > > > On Apr 11, 2022, at 5:02 PM, Mat Carter > > wrote: > > > > Thanks, Weijun > > > > Let's move ahead with the two new strings while we consider read-only > > access. As the current assignee can you update the JBS issue [1] with what > > we've agreed here. > > > > I have an implementation that I've been testing in 11u which can easily > > move to tip; if you are happy for me to make the changes then please ack > > here and re-assign the issue to me > > > > [1] > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Cf46a1e0bd128483c980f08da1c0b40e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637853131938100906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FcdLRJAf8TyNNQjc7Pw9vDBnLNBZ%2BhIjQ17MDMPUqIg%3D&reserved=0 > > > > > > Thanks > > Mat >
Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
Weijun Here's a PR [1] if you would like to review and consider sponsoring [1] https://github.com/openjdk/jdk/pull/8211 Cheers Mat Sent from Outlook<http://aka.ms/weboutlook> From: Wei-Jun Wang Sent: Monday, April 11, 2022 3:33 PM To: Mat Carter Cc: Bernd Eckenfels ; security-dev@openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Added a comment and assigned the enhancement to you. Thanks. --Weijun > On Apr 11, 2022, at 5:02 PM, Mat Carter wrote: > > Thanks, Weijun > > Let's move ahead with the two new strings while we consider read-only access. > As the current assignee can you update the JBS issue [1] with what we've > agreed here. > > I have an implementation that I've been testing in 11u which can easily move > to tip; if you are happy for me to make the changes then please ack here and > re-assign the issue to me > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Cf46a1e0bd128483c980f08da1c0b40e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637853131938100906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FcdLRJAf8TyNNQjc7Pw9vDBnLNBZ%2BhIjQ17MDMPUqIg%3D&reserved=0 > > > Thanks > Mat
Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
Added a comment and assigned the enhancement to you. Thanks. --Weijun > On Apr 11, 2022, at 5:02 PM, Mat Carter wrote: > > Thanks, Weijun > > Let's move ahead with the two new strings while we consider read-only access. > As the current assignee can you update the JBS issue [1] with what we've > agreed here. > > I have an implementation that I've been testing in 11u which can easily move > to tip; if you are happy for me to make the changes then please ack here and > re-assign the issue to me > > [1] https://bugs.openjdk.java.net/browse/JDK-6782021 > > > Thanks > Mat
Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
Thanks, Weijun Let's move ahead with the two new strings while we consider read-only access. As the current assignee can you update the JBS issue [1] with what we've agreed here. I have an implementation that I've been testing in 11u which can easily move to tip; if you are happy for me to make the changes then please ack here and re-assign the issue to me [1] https://bugs.openjdk.java.net/browse/JDK-6782021 Thanks Mat Sent from Outlook<http://aka.ms/weboutlook> From: Wei-Jun Wang Sent: Monday, April 11, 2022 11:45 AM To: Mat Carter Cc: Bernd Eckenfels ; 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 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 on behalf of Bernd > Eckenfels > Sent: Tuesday, April 5, 2022 11:20 AM > To: 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 > > -- > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eckenfels.net%2F&data=05%7C01%7CMatthew.Carter%40microsoft.com%7C9492ccb410834f633f4708da1beb6d02%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637852995228154570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qjRXhchorKHZFaQY4zuwXqSwVjmda7HkWJEN%2FtMeaT4%3D&reserved=0 > Von: security-dev im Auftrag von Mat > Carter > Gesendet: Dienstag, April 5, 2022 5:22 PM > An: Wei-Jun Wang > Cc: 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 >
Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
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 Sent: Monday, April 11, 2022 8:45:12 PM To: Mat Carter Cc: Bernd Eckenfels ; 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 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 on behalf of Bernd > Eckenfels > Sent: Tuesday, April 5, 2022 11:20 AM > To: 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 im Auftrag von Mat > Carter > Gesendet: Dienstag, April 5, 2022 5:22 PM > An: Wei-Jun Wang > Cc: 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 acces
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 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 on behalf of Bernd > Eckenfels > Sent: Tuesday, April 5, 2022 11:20 AM > To: 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 im Auftrag von Mat > Carter > Gesendet: Dienstag, April 5, 2022 5:22 PM > An: Wei-Jun Wang > Cc: 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 > Sent: Friday, April 1, 2022 3:15 PM > To: Mat Carter > Cc: security-dev@openjdk.java.net > Subject: Re: Proposal: Extend Windows KeyStore support to include access to > the local machine location > > Hi Mat, > >
Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
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<http://aka.ms/weboutlook> From: security-dev on behalf of Bernd Eckenfels Sent: Tuesday, April 5, 2022 11:20 AM To: 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 im Auftrag von Mat Carter Gesendet: Dienstag, April 5, 2022 5:22 PM An: Wei-Jun Wang Cc: 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 Sent: Friday, April 1, 2022 3:15 PM To: Mat Carter Cc: 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 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
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 im Auftrag von Mat Carter Gesendet: Dienstag, April 5, 2022 5:22 PM An: Wei-Jun Wang Cc: 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 Sent: Friday, April 1, 2022 3:15 PM To: Mat Carter Cc: 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 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): > > "
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 Sent: Friday, April 1, 2022 3:15 PM To: Mat Carter Cc: 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 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 >
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 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://docs.microsoft.com/en-us/windows/win32/seccrypto/system-store-locations > [2] https://bugs.openjdk.java.net/browse/JDK-6782021 > [3] > http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017832.html > [4] > https://stackoverflow.com/questions/70200603/accessing-windows-local-machine-certificates-from-a-windows-service-written-in-j > [5] > https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java > > > Sent from Outlook
Proposal: Extend Windows KeyStore support to include access to the local machine location
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://docs.microsoft.com/en-us/windows/win32/seccrypto/system-store-locations [2] https://bugs.openjdk.java.net/browse/JDK-6782021 [3] http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017832.html [4] https://stackoverflow.com/questions/70200603/accessing-windows-local-machine-certificates-from-a-windows-service-written-in-j [5] https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java Sent from Outlook
