Re: SECOM Request for EV Treatment
2015年11月13日金曜日 23時27分46秒 UTC+9 Kathleen Wilson: > On 11/13/15 5:43 AM, Peter Kurrasch wrote: > > Kathleen, is SECOM getting special treatment? I was wondering if there was > > some reason to move forward before a CA has everything in order? Will we be > > seeing more of this going forward? > > > > I thought everything was in order, except perhaps there might be a few > more suggestions to updating their CPS that could be tracked in parallel > (i.e. not show stoppers). We have done that in the past, and Ryan had > sent me email saying that he might not be able to participate in the > inclusion review discussions for a while, so to go forward without him. > > But as you can see in the bug I realized that was not quite the case > when I went to write the summary to recommend approval. So, in the bug I > clarified that SECOM needs to make further updates to their CP/CPS > before we can move forward. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1096205#c28 > > So, it was not intentional. > > However, I would like to get the root inclusion/update discussions > moving forward again -- those discussions have stalled out. > > Kathleen Dear Kathleen-san, The updated CP for detailed descrition(the certificate subscriber owns/controls) about domain verification for the section 3.2.7 is attached on bugzilla. https://bugzilla.mozilla.org/attachment.cgi?id=8689921 Email address verification does not apply to this EV SSL CP/CPS. The corresponding section were made comprehensible by blue characters. Thank you for your consideration. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal: Require full CP/CPS in English
On Thu, Nov 19, 2015 at 05:00:03PM -0800, Kathleen Wilson wrote: > Insert 3rd bullet point: > "- translate into English the Certificate Policy and Certification Practice > Statement documents pertaining to the certificates to be included and the > trust bits to be enabled;" > > I will appreciate recommendations about how to improve this proposed update. Some wording to require CAs to acknowledge that this translation is not merely informative, but in fact a binding agreement with the Internet community, would be useful. I can easily imagine a CA claiming, in the event of a breach of the CPS, that the "authoritative" version, in an alternate language, doesn't describe things in quite the same way, and so isn't a breach. > Is this a reasonable requirement to add? I think it is. The working language of the technical Internet (and this list) is, for better or worse, English, and ensuring that the core documentation of a CA's agreement with the Internet community is consumable by the largest possible number of interested parties is an important goal. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Name issues in public certificates
Patrick T writes: >I've found one of the certificates here (*.gov.bn, Symantec issued) seems to >contain some NULL characters in the SAN. Wow, you're right: 673 359: SEQUENCE { 677 33: SEQUENCE { 6793: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 684 26: OCTET STRING, encapsulates { 686 24: SEQUENCE { 6888: [2] '*.gov.bn' 698 12: [2] 00 5A 37 00 2A 2E 67 6F 76 2E 62 6E : } : } : } The tail end of that is *.gov.bn, no idea what the four bytes before that are. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy Update Proposal: Require full CP/CPS in English
I would like to discuss this proposal[1] next: - (D26) Add a requirement for CAs to provide English-translated versions of their complete CP / CPS I think we would have to narrow it down a bit, because some CAs have several CP/CPS documents for their various product offerings, not related to SSL or S/MIME certs. So, how about if we add a bullet point to section 6 of the Inclusion policy, which currently starts as follows. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ ~~ 6. We require that all CAs whose certificates are distributed with our software products: - provide some service relevant to typical users of our software products; - publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement); ~~ Insert 3rd bullet point: "- translate into English the Certificate Policy and Certification Practice Statement documents pertaining to the certificates to be included and the trust bits to be enabled;" I will appreciate recommendations about how to improve this proposed update. Is this a reasonable requirement to add? Are there any arguments against adding this requirement that we should consider? Thanks, Kathleen [1] https://wiki.mozilla.org/CA:CertificatePolicyV2.3 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Name issues in public certificates
On Thu, Nov 19, 2015 at 4:26 PM, Brian Smith wrote: > Peter Bowen wrote: >> >> Robin Alden wrote: >> Given that it doesn't, but that that the BRs say "MUST be either a >> dNSName containing the Fully‐Qualified Domain Name or an iPAddress >> containing the IP address", it is clear we still need to have a valid >> FQDN. I'll update my scanner to allow "_" in the labels that are not >> registry controlled or in the label that is immediately to the left of >> the registry controlled labels. Give me a little while and I'll >> upload a revised data set with this fix. > > > See https://bugzilla.mozilla.org/show_bug.cgi?id=1136616. In mozilla::pkix, > we had to allow the underscore because of AWS. Touche :) It looks like S3 allows underscores but calls out that they are not DNS compliant (http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html). People accessing these buckets should be using the https://s3.amazonaws.com/$BUCKET/$KEY URL format, not the https://$BUCKET.s3.amazonaws.com/$KEY URL format. I will talk to the S3 team about ensuring that all names published in DNS are compliant with RFC 1123. That being said, I updated the spreadsheet to allow underscores in both the CN and dNSName generalName. Please note that the updated sheet has a slightly different column order. I also added rules to check for nulls in dNSNames (one hit), unparsable ASN.1 in the subjectAltName extension (23 hits), and basic validation for RFC822Names in SANs (even though they are not allowed in by the BRs). The sheet is available at: https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing As always, I welcome feedback. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update: section 8 of Maintenance Policy
There are two proposals on the table... Proposal A: ~~ 8. We consider the algorithms and key sizes specified in section 6.1.5 of version 1.3 or later of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates to be acceptable and supported in Mozilla products; with the following exceptions. - Mozilla does not and will not support DSA keys - Mozilla does not currently support ECC curve P-521 ~~ Proposal B: ~~ 8. We consider the following algorithms and key sizes to be acceptable and supported in Mozilla products: - ECDSA using the P-256 curve and SHA-256. - ECDSA using the P-384 curve and SHA-384. - RSA using a 2048-bit or larger modulus, using SHA-256, SHA-384, or SHA-512. ~~ I believe that both proposals say basically the same thing. Proposal A might not a good idea if the BRs are ever updated to add key sizes or algorithms that Mozilla does not actually support. But updating the BRs does require a vote in the CA/Browser Forum, so I think it's safe to assume that Mozilla would be involved in any such changes. I think Proposal A is easier to maintain. I think Proposal B is easier to read and understand. Proposal B will have to be updated every time something changes. So, at this point I vote for Proposal A. What do you all think? Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Name issues in public certificates
Peter Bowen wrote: > Robin Alden wrote: > Given that it doesn't, but that that the BRs say "MUST be either a > dNSName containing the Fully‐Qualified Domain Name or an iPAddress > containing the IP address", it is clear we still need to have a valid > FQDN. I'll update my scanner to allow "_" in the labels that are not > registry controlled or in the label that is immediately to the left of > the registry controlled labels. Give me a little while and I'll > upload a revised data set with this fix. See https://bugzilla.mozilla.org/show_bug.cgi?id=1136616. In mozilla::pkix, we had to allow the underscore because of AWS. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal: Timeline for Disclosing SubCAs
By the time version 2.3 of Mozilla’s CA Cert Policy is published, I hope to have issued a CA Community License to every included CA. Taking that into consideration; I propose changing the policy as follows. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ “10. … The CA with a certificate included in Mozilla’s CA Certificate Program MUST disclose this information *in the CA Community in Salesforce* https://wiki.mozilla.org/CA:SalesforceCommunity> before any such subordinate CA is allowed to issue certificates *chaining up to the CA’s included root certificate*. …” Additionally, I also propose that we change the first bullet point in this section, because in the CA Community in Salesforce the CA is expected to copy-paste in the contents of the .pem file for the intermediate cert. “10. … For a certificate to be considered publicly disclosed and audited, the following information MUST be provided: ..." CURRENT text: "- The full DER-encoded X.509 certificate (Each issuing CA should provide one .p7c, .zip, or .tgz file containing all of the non-technically-constrained intermediate certificates that it has signed.); …” CHANGE to: “- The PEM (Privacy-enhanced Electronic Mail) Base64 encoded DER X.509 certificate, enclosed between "-BEGIN CERTIFICATE-" and "-END CERTIFICATE-";” Also, in the https://wiki.mozilla.org/CA:SalesforceCommunity wiki page I propose adding the following section: == When to Add Intermediate Certificate Data == As per Mozilla’s CA Certificate Inclusion policy, all certificates that are capable of being used to issue new certificates, that are not technically constrained (via Extended Key Usage and Name Constraint settings), and that directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program MUST be audited in accordance with Mozilla’s CA Certificate Policy and MUST be publicly disclosed by the CA that has their certificate included in Mozilla’s CA Certificate Program. The CA with a certificate included in Mozilla’s CA Certificate Program MUST add the PEM-encoded X.509 intermediate certificate and the corresponding CP/CPS and Audit documentation to the CA Community in Salesforce before the subordinate CA begins issuing Publicly-Trusted Certificates that chain up to the CA’s included root certificate. ~~ As always, I will appreciate your thoughtful and constructive input about this proposal. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certum Root Renewal Request
On 10/21/15 12:28 PM, Kathleen Wilson wrote: On 10/1/15 3:44 PM, Kathleen Wilson wrote: Unizeto Certum has applied to include the “Certum Trusted Network CA 2” root certificate, turn on all three trust bits, and enable EV treatment. This is the next generation of the “Certum Trusted Network CA” root cert that was included via bug #532377. Does anyone have any comments, questions, or concerns about this request from Unizeto Certum? Kathleen Are there any further comments on this request, or is it OK to proceed with recommending approve with the caveat that we are no longer turning on the code signing trust bit for roots? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Name issues in public certificates
On Thu, Nov 19, 2015 at 11:57 AM, Robin Alden wrote: > Peter said.. >> While I realize that it is not clear cut in many contexts, RFC 5280 is >> rather clear cut. The authors clearly wanted to avoid stumbling and >> being eaten by a grue, so they wrote: >> >>When the subjectAltName extension contains a domain name system >>label, the domain name MUST be stored in the >>dNSName (an IA5String). >>The name MUST be in the "preferred name syntax", as specified by >>Section 3.5 of [RFC1034] and as modified by Section 2.1 of >>[RFC1123]. >> >> This makes it clear that the "preferred name syntax" is not a >> recommendation when it comes to certificates. It is mandatory. > > Ah, but the lead-in there is > "When the subjectAltName extension > contains a domain name system label," > > weird_place.example.com is not a domain name system label. It is not > expected to (and likely does not, and maybe could not) resolve to an IP > address on the public internet. Yes, reading again I agree that the language there leaves it open that the dNSName type might not contain a domain name system label. If the authors truly wanted to avoid the grue, they should have said: "When the subjectAltName extension contains a dNSName, the dNSName must contain a domain name." (or domain name system label). Given that it doesn't, but that that the BRs say "MUST be either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress containing the IP address", it is clear we still need to have a valid FQDN. I'll update my scanner to allow "_" in the labels that are not registry controlled or in the label that is immediately to the left of the registry controlled labels. Give me a little while and I'll upload a revised data set with this fix. > In practice, the people to whom weird_place.example.com is a useful name > will be running Microsoft kit which is very happy with an underscore in > a name. All that matters to them is that weird_place.example.com > resolves within their environment. > The CAB Forum BRs can be met in the validation of such a certificate > providing that ownership or control of example.com is shown in the > approved methods. The BRs place no requirement on the full name > weird_place.example.com appearing on the internet or being accessible by > the CA. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Name issues in public certificates
Peter said.. > While I realize that it is not clear cut in many contexts, RFC 5280 is > rather clear cut. The authors clearly wanted to avoid stumbling and > being eaten by a grue, so they wrote: > >When the subjectAltName extension contains a domain name system >label, the domain name MUST be stored in the >dNSName (an IA5String). >The name MUST be in the "preferred name syntax", as specified by >Section 3.5 of [RFC1034] and as modified by Section 2.1 of >[RFC1123]. > > This makes it clear that the "preferred name syntax" is not a > recommendation when it comes to certificates. It is mandatory. Ah, but the lead-in there is "When the subjectAltName extension contains a domain name system label," weird_place.example.com is not a domain name system label. It is not expected to (and likely does not, and maybe could not) resolve to an IP address on the public internet. In practice, the people to whom weird_place.example.com is a useful name will be running Microsoft kit which is very happy with an underscore in a name. All that matters to them is that weird_place.example.com resolves within their environment. The CAB Forum BRs can be met in the validation of such a certificate providing that ownership or control of example.com is shown in the approved methods. The BRs place no requirement on the full name weird_place.example.com appearing on the internet or being accessible by the CA. Regards Robin 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: Certum Root Renewal Request
Hi We've provided code signing certificates to our customers for many years. Also, at this time, the new root CTNCA 2 is going to be used for this purpose. When it comes to a specific group of customers, I would say it appears that we don't have customers who need to use our root from NSS root store for code signing purposes. Tt is possible that they exist but we do not know anything about it. Therefore, we are not opposed to the removal of trust bits from our and other root certificates. Yours Sincerely Arkadiusz Ławniczak ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Name issues in public certificates
On Tuesday, 17 November 2015 08:04:41 UTC, Peter Bowen wrote: > Inspired by Rob Stradling's work > (https://cabforum.org/pipermail/public/2015-November/006269.html), I > wrote a quick tool to check that commonNames and Subject Alternative > Names in server auth certificates issued by public CAs were following > the CA/Browser Forum baseline requirements. > > The resulting report of anomalies is available at > https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing > > The rules are a rather strict interpretation of RFC 5280 and the > Baseline Requirements. Notably, it will complain if FQDNs are not > converted to ASCII (as defined in 7.2 and 7.3 of RFC 5280) and will > complain if there is an IP address flaged as a dNSName in a > Generalized Name. > > There are a couple of rules that may create false positives, so please > don't assume every certificate on the sheet is problematic. > > Thanks, > Peter I've found one of the certificates here (*.gov.bn, Symantec issued) seems to contain some NULL characters in the SAN. https://crt.sh/?serial=331C896050CE23EFAB5CF53237AF093F and https://crt.sh/?id=7335256 Wasn't there an issue with spoofing using NULs in certificates several years ago? Verisign back then claimed this couldn't be done, but the cert is recent. http://www.symantec.com/connect/blogs/busy-day-black-hat ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy