Re: KIR S.A. Root Inclusion Request
Answers for Matt Palmer questions: On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@gmail.com wrote: As you can see above in the same point of CPS: To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Rights to the domain is indicated there as being optional, and I can't find any indication in the CPS of which certificate types will be domain-validated. Also, the only place I've found a description of your domain validation practices is at the bottom of CPS s3.2.2, which only mentions having information placed on a server. My reading of the e-mail communication option is for purposes other than domain validation. Can you confirm that is the case? CSP s3.2 concerns all type of certificates. Optional, relevant to the certificate type means that we don't ask for domain validation for e.g. the standard certificate. We do domain validation for all SSL certifcates. More details about process of validation during issuing certificates of all types you can find in CP. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. Only issuing test cerificate we don't ask subscriber for visiting our RA. Below you can find one example from CPS of CA which root certificates is inclued in the Mozilla browser: Registration might require subscriber or a representative authorized by the subscriber to personally attend a registration authority. Nevertheless, CERTUM permits (for specified certificate types) sending applications for registration by mail, electronic mail, WWW sites, etc.; examination of the applications does not necessitate a physical contact with the requester. We reserve itself the right to downtime our OCSP, but it doesn't mean that we do it every week during normal working hours. What is acceptable level of service for you? We can adjust our technical downtime for OCSP. 100%. OCSP is a fundamental service for a publically-trusted CA to provide. Given that it can easily be run as a read-only service for a period of time (in your case, up to 24 hours), there is no reason why maintenance cannot be done entirely without interruption. We maintain OCSP on line 24x7. But 100% availability of is utopia. Even e- banking systems have their downtimes. We want to be fair to the user, that's why we inform them about possibility of downtime. We can remove this 4 hour from CSP. Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł. Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu. The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you are not an indicated recipient, you must not copy, distribute or take any action in reliance on it. If received in error, please notify the sender by return email and delete his transmission (and any attachments) from your system. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 13:43, Steve Roylance wrote: You can encrypt communications if you have a public/private key pair You can; although most often that's provided by the server in the model of computing most prevalent on the web today. You can digitally sign (with the full support of digital signature laws) Yep, OK. Through federation you can use your ID in multiple places Well, you can carry the widget around too :-) I agree that it would be great for all members of the eco system to work together to improve some of the issues you say are disadvantages, but I do disagree with one of your items. A digital certificate has an end date. A secure key has a battery with no specific end date so one definitely has no warning capability. Well, often there's a battery low message or light. Whereas I think it's most people's experience that certificate-use UIs don't pop up helpful messages like Hey, this cert you are using expires in a week. have you thought about getting a new one? And yes, I take your point about improving the UX... but that was where my thoughts started. Perhaps the reason that the client cert UX is unloved is that they don't meet common use cases? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 13:45, Michał Purzyński wrote: In order to leak the private cert you need to compromise the host. Leaking the password is easier - you can compromise the web application, the target server, the target company or the client’s machine. You have a few more attack vectors with passwords. Passwords get leaked on things like pastebin. The output of a widget like the one I linked to is not a password in the sense you mean with most of your criticisms. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 13:53, Kurt Roeckx wrote: On 2014-09-25 14:29, Gervase Markham wrote: A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? You seem to be under the impression that client certificates can't be on a token. No, I understand that can be true. But then the question is why bother, as putting a cert on a token, as opposed to having a screen you read a number off, simply means that you can only use it on a computer which has an appropriate and available slot for the token to go into. (And then, you have the problem that token operations could be taking place without your knowledge.) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 2014-09-25 15:12, Gervase Markham wrote: simply means that you can only use it on a computer which has an appropriate and available slot for the token to go into. They can usually be connected using USB, but it's probably not easy to connect that to your phone, and you probably don't always have that with you. (And then, you have the problem that token operations could be taking place without your knowledge.) If your software doesn't ask you to confirm before using your certificate, something seems to be wrong to me. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Indicators for high-security features
On Mon, Sep 22, 2014 at 2:47 PM, fhw...@gmail.com wrote: To the larger discussion, I have 2 questions: 1) what is the specific message you'd like to convey to the user beyond what the simple lock icon provides. That the site not only uses authenticated https but uses authenticated https *better*. (I think forward secrecy and HSTS can be considered the main ingredients of better.) The bar for the old lock is pretty low: You get the old lock with SSL3, RSA key transport and RC4 without HSTS. However, just changing the criteria for the old lock would probably have the effect of crying wolf, since so many currently lock-bearing sites don't meet the better criteria. 2) What action do you intend the user to take based on seeing the new indicator? I expect most users not to take any action. I'd expect site admins who see the new indicator on someone else's site to thing Why does the other site have a cooler lock than mine? I want the cooler lock, too. and then learn how to get the cooler lock. I'd also expect a small group of technically informed users, who currently don't bother inspecting the ciphersuite and HSTS state of sites, to nag sites that they use but that don't have the new indicator to fix their act to get the new indicator. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: KIR S.A. Root Inclusion Request
Hi Przemyslaw, 1) Suspension I can see that it's no problem for a certificate's status as shown in OCSP or in a CRL (as viewed from outside your organization) to transition from valid to 'Revoked' as a result of a 'suspension' within your system. The problem comes when you try to 'unsuspend'. You can't transition back from 'revoked' to valid. http://www.ietf.org/rfc/rfc5280.txt 3.3. Revocation ... An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. Regards Robin Alden -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+robin=comodo@lists.mozilla.org] On Behalf Of Certificates Sent: 25 September 2014 14:03 To: dev-security-policy@lists.mozilla.org Subject: Re: KIR S.A. Root Inclusion Request Answers for Jeremy Rowley questions: A couple of notes: 1) Under Section 3.4 and 4.9, suspension is not permitted for SSL certs under the BRs. Where the BR forbids certificates suspension? The Repository gives an answer revoke for suspended certificate, so it's consistent withe BR s13.2.7. 2) Section 3.3 should specify when re-verification is required (at least every 39 months). Although the CPS does say the original issuance process is followed, I didn't this specified at the certificate lifecycle is 5 years. Also, be aware that five year certs are only permitted until April 1, 2015. After that, the maximum lifecycle is 39 months Yes, we know about this requirement. Presently, we do not issue certificates above 2 years validity period, although we mentioned such possibility in CPS. We do verification both for first certificate and renewal, in particular we verify rights to domain for SSL certificates. Our internal procedures describe this process in details. 3) See section 13.1.5 of the BRs for the reasons a CA must revoke a certificate. Section 4.9 of your CPS doesn't really match these. The reasons for revoking subscriber certificate pointed in CSP corresponds to the reasons pointed in BR. But if the connection isn't clear we can clarified it more in CSP by introducing some changes. 4) Archiving is required for 7 years under the BRs (5.4.3 and 5.5). That's a mistake in CPS. We will change it. 5) 6.28 should require at least two individuals acting together to activate the private key It is done by two persons. It is mentioned in CPS s.6.2.2 that the secrets are distributed among 5 persons. CSP s6.2.6. Uploading a private key to cryptographic modules is done in the following situations: 1) launch of the certification authority during the system start-up; 2) recovery of the key of the certification authority in the back-up location; 3) replacement of the cryptographic module. The key is uploaded to the module with the presence of the holders of co-shared secrets. To upload the key it is necessary to have the presence of the number of secrets described in Clause 6.2.2. Uploading is done within a closed security environment. A private key is made up of elements. Parts of the secret key from the cards are provided in sequence, enciphered files are uploaded into the module's memory and then deciphered. A private key is ready to use. Uploading of the key into the module is recorded in the register of events. CSP s.6.2.8 Once uploaded into the module, the key shall be active. 6) Some of your EKU extensions are not permitted in the same certificate. We are aware of it. In the SSL certificates we use only clientAuthentication and serverAuthentication. 7) Note the recently announced SHA-2 requirement. SHA-1 is the only hash specified in the CPS. 5 year certificates will not be possible. We are aware of it and we will start issuing certificates with SHA 256 before this date and also supplement our CSP accordingly. 8) What is your OCSP response for a not issued cert? The answer is unknown - CSP s4.9.9. Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł. Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu. The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you
RE: Client certs
Hi Gerv, I can send out a million client certificates for negligible cost. That is especially attractive cost-wise for an existing system that I have to increase the security of (say over username and password), but which has not been identified as needing 2 factor authentication. Sending out a million anythings by snail-mail is spendy. If you could rely on the user already having the number-sequence widget, or of having a virtual widget on their smartphone (like Google Authenticator) then the cost argument is irrelevant. Regards Robin -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+robin=comodo@lists.mozilla.org] On Behalf Of Gervase Markham Sent: 25 September 2014 13:29 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Client certs A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? http://www.hsbc.co.uk/1/2/customer-support/online-banking- security/secure-key It seems like they have numerous disadvantages (some subjective): * Client certs can be invisibly stolen if a machine is compromised * Client certs are harder to manage and reason about for an average person * Client certs generally expire and need replacing, with no warning * Client certs are either single-machine, or need a probably-complex copying process What are the advantages? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: KIR S.A. Root Inclusion Request
If you look under Section 13.2.4, a CA cannot remove an entry from its CRLs, meaning there is no way to un-suspend a certificate. On 9/25/2014 7:03 AM, Certificates wrote: Answers for Jeremy Rowley questions: A couple of notes: 1) Under Section 3.4 and 4.9, suspension is not permitted for SSL certs under the BRs. Where the BR forbids certificates suspension? The Repository gives an answer revoke for suspended certificate, so it's consistent withe BR s13.2.7. 2) Section 3.3 should specify when re-verification is required (at least every 39 months). Although the CPS does say the original issuance process is followed, I didn't this specified at the certificate lifecycle is 5 years. Also, be aware that five year certs are only permitted until April 1, 2015. After that, the maximum lifecycle is 39 months Yes, we know about this requirement. Presently, we do not issue certificates above 2 years validity period, although we mentioned such possibility in CPS. We do verification both for first certificate and renewal, in particular we verify rights to domain for SSL certificates. Our internal procedures describe this process in details. 3) See section 13.1.5 of the BRs for the reasons a CA must revoke a certificate. Section 4.9 of your CPS doesn't really match these. The reasons for revoking subscriber certificate pointed in CSP corresponds to the reasons pointed in BR. But if the connection isn't clear we can clarified it more in CSP by introducing some changes. 4) Archiving is required for 7 years under the BRs (5.4.3 and 5.5). That's a mistake in CPS. We will change it. 5) 6.28 should require at least two individuals acting together to activate the private key It is done by two persons. It is mentioned in CPS s.6.2.2 that the secrets are distributed among 5 persons. CSP s6.2.6. Uploading a private key to cryptographic modules is done in the following situations: 1) launch of the certification authority during the system start-up; 2) recovery of the key of the certification authority in the back-up location; 3) replacement of the cryptographic module. The key is uploaded to the module with the presence of the holders of co-shared secrets. To upload the key it is necessary to have the presence of the number of secrets described in Clause 6.2.2. Uploading is done within a closed security environment. A private key is made up of elements. Parts of the secret key from the cards are provided in sequence, enciphered files are uploaded into the module's memory and then deciphered. A private key is ready to use. Uploading of the key into the module is recorded in the register of events. CSP s.6.2.8 Once uploaded into the module, the key shall be active. 6) Some of your EKU extensions are not permitted in the same certificate. We are aware of it. In the SSL certificates we use only clientAuthentication and serverAuthentication. 7) Note the recently announced SHA-2 requirement. SHA-1 is the only hash specified in the CPS. 5 year certificates will not be possible. We are aware of it and we will start issuing certificates with SHA 256 before this date and also supplement our CSP accordingly. 8) What is your OCSP response for a not issued cert? The answer is unknown - CSP s4.9.9. Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł. Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu. The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you are not an indicated recipient, you must not copy, distribute or take any action in reliance on it. If received in error, please notify the sender by return email and delete his transmission (and any attachments) from your system. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy . ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
Also, policy and authorization is often embedded in client certs. Software that knows how to read this information can provide permissions based on the included policy. This is used by first responders and large distributed networks where the credential acts as their permission to participate and sets the level of participation. IMO, the two really aren't comparable. Sure, there is an overlap for the two-factor authentication portion, but certs are pretty flexible in what you can do. For example, we have some people who restrict use of their software to a particular intermediate (similar to key pinning but before key pinning existed), use client certs to sign documents (without a signing portal), use certs to encrypt email, use certs for scheduling, use certs for directed exchange, etc. Jeremy On 9/25/2014 10:53 AM, Robin Alden wrote: Hi Gerv, I can send out a million client certificates for negligible cost. That is especially attractive cost-wise for an existing system that I have to increase the security of (say over username and password), but which has not been identified as needing 2 factor authentication. Sending out a million anythings by snail-mail is spendy. If you could rely on the user already having the number-sequence widget, or of having a virtual widget on their smartphone (like Google Authenticator) then the cost argument is irrelevant. Regards Robin -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+robin=comodo@lists.mozilla.org] On Behalf Of Gervase Markham Sent: 25 September 2014 13:29 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Client certs A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? It seems like they have numerous disadvantages (some subjective): * Client certs can be invisibly stolen if a machine is compromised * Client certs are harder to manage and reason about for an average person * Client certs generally expire and need replacing, with no warning * Client certs are either single-machine, or need a probably-complex copying process What are the advantages? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: HSTS
I'll address the DoS thing momentarily but first I'm curious if there's any data out there on how widely deployed HSTS currently is and/or to what extent site/domain owners are committing to support it going forward?Also are the cases where self-DoS might occur well known? The cases I can think of generally fall into 3 different categories, but since the actual ways in which you might shoot yourself in the foot are numerous (and subtle) I'd argue that choosing to implement HSTS is a much larger commitment than HTTPS alone. For one thing, you need knowledge of your whole domain and the content being delivered (and how it's being deployed) or you run the risk of screwing something up.You hit upon one such case below, where a subdomain that doesn't have SSL becomes inaccessible due to the "includeSubdomains" flag. Actually the other case is a problem too, but for illustration purposes I'll talk about the former.So, consider a brand like Nike who has a large internet presence and a lot of products serving different people and markets. I don't personally know anything about them or how they get their internet needs met, but let's just assume for this discussion they have a bunch of different teams and outsourcing agreements that try to make it all work (something I think could be said for all major corporations).Next, let's suppose they want to run a marketing campaign during a major sports event and give away free shoes to the first 500 people who sign up at a new micro site setup just for this campaign. The browser requests go something like this (substituting - for. )1. Go to the landing page at freeshoes-nike-com using http2. Grab some some logo graphics from nike-com using https, hsts is enabled with includesubdomains3. Grab a js file at freeshoes-nike-com that will collect people's information using http, which is rewritten to be https but a cert was never installed for "freeshoes"Clearly you are screwed, the page will not display correctly. And if you try to go back to the landing page (with just http), you're even worse off because then nothing shows up, only the error screen. People will be very upset, especially the marketing team who can do nothing but watch their campaign blow up before their very eyes.Put simply, a debacle such as this would be a very big deal, and no matter how much people might like the idea of security there is not a person out there who wants to risk losing their job just to be more secure.So that's why I have a hard time seeing HSTS becoming widely adopted. Maybe it will make my site more secure but if it's going to screw everything up, I'm not interested. Bait-and-switch.Some of the other DoS cases might be even more problematic, but I don't know if anyone wants to get into them here.Thanks. From: David KeelerSent: Wednesday, September 24, 2014 12:32 PMOn 09/23/2014 10:03 PM, fhw...@gmail.com wrote:...snip... The shortcoming of HSTS is on the deployment side, where on the one hand it purports to help web app developers and deployment teams who falter at security and on the other hand gives those same people all-new ways to falter at security. It's your classic bait-and-switch except this time your site could become unusablesnip...A site can only DOS itself if it sets a long-lived header and then stopssupporting https (or if it sets includeSubdomains and a subdomaindoesn't support https). The easy answer is if your site is committed toalways supporting https, then HSTS is appropriate. If not, then it isn'tappropriate. The most ambitious of web sites and services will be up for the challenge of doing a proper HSTS implementation but the rest...I don't know. Any thoughts on how widely this will be adopted?Again, using HSTS is essentially as difficult as using https properly.If that's doable (and it's definitely a whole lot easier than it used tobe), then setting an HSTS header is a small incremental step that doesincrease a site's security. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Security Blog about SHA-1
- Original Message - From: Chris Palmer pal...@google.com To: Chris Egeland ch...@chrisegeland.com Cc: mozilla-dev-security-pol...@lists.mozilla.org dev-security-policy@lists.mozilla.org Sent: Wednesday, 24 September, 2014 11:53:58 PM Subject: Re: Security Blog about SHA-1 Also, there's no problem (from a Chrome UX perspective) because Mozilla's certificate expires on 7 December 2015 — well before that bad 1 Jan 2017 date, and even before the dodgy 1 Jan 2016 date. http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html SHA-1 signature algorithms are not per se bad right now; what's bad is certificate chains using SHA-1 that will/would be valid too far in the future. Between now and 1 Jan 2016, and between then and 1 Jan 2017, there is plenty of time to get a new certificate, signed with a SHA-256-based signature function. It's debatable if the 2016 date is good. NIST doesn't agree but yes, as far as Internet certs go, mozilla one is not so bad -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
