Re: New Module Owner for CA Certificate Policy

[Peter Saint-Andre via dev-security-policy]

Thanks to both you and Wayne (and Ryan) for your exemplary work on this
important module.

On 10/22/18 12:05 PM, Kathleen Wilson via dev-security-policy wrote:
> I have made this change:
> https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy
> 
> Thanks,
> Kathleen
> 
> On 10/13/18 9:39 AM, Kathleen Wilson wrote:
>> All, I posted the following in the mozilla.governance forum.
>>
>> Please feel free to comment here in m.d.s.policy, if you would like.
>>
>> ~~
>>
>> I’m proposing to make Wayne Thayer the new owner of the “CA
>> Certificate Policy” module. In his role at Mozilla, Wayne has been
>> driving updates to Mozilla’s Root Store Policy and has been enforcing
>> Mozilla’s policies governing Certification Authorities (CAs) for the
>> past year. Wayne led the effort to release versions 2.6 and 2.6.1 of
>> Mozilla’s Root Store Policy[1], has helped resolve over 70 CA
>> compliance bugs[2], and is actively pursuing resolution to over 50
>> open CA compliance bugs[3].
>>
>> There are two modules related to Mozilla’s CA Program which govern the
>> default set of certificates in Network Security Services (NSS) and
>> distributed in Mozilla’s software products. They are:
>>
>> 1) Mozilla CA Certificate Policy[4]
>> Description: Definition and enforcement of policies governing
>> Certification Authorities, their root certificates included in Mozilla
>> software products, and intermediate and end-entity certificates within
>> those CA hierarchies.
>> Current Owner: Kathleen Wilson -- Proposed Owner: Wayne Thayer
>> Current Peer(s): Wayne Thayer -- Proposed Peer: Kathleen Wilson
>>
>> 2) CA Certificates[5]
>> Description: Determine which root certificates should be included in
>> Mozilla software products, which trust bits should be set on them, and
>> which of them should be enabled for EV treatment. Evaluate requests
>> from Certification Authorities (CAs) for inclusion or removal of root
>> certificates, and for updating trust bit settings or enabling EV
>> treatment for already included root certificates.
>> Owner: Kathleen Wilson  -- no change
>> Peer(s): Ryan Sleevi, Wayne Thayer -- no change
>>
>> Thanks,
>> Kathleen
>>
>> [1]
>> https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/
>> [2] https://wiki.mozilla.org/CA/Closed_Incidents
>> [3] https://wiki.mozilla.org/CA/Incident_Dashboard
>> [4] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy
>> [5] https://wiki.mozilla.org/Modules/All#CA_Certificates
>>
>> ~~
>>
> 
> ___
> 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: Certificates with improperly normalized IDNs

[Peter Saint-Andre via dev-security-policy]

On 6/25/18 1:35 PM, swchang10--- via dev-security-policy wrote:
> On Friday, August 11, 2017 at 6:54:22 AM UTC-7, Peter Bowen wrote:
>> On Thu, Aug 10, 2017 at 1:22 PM, Jonathan Rudenberg via
>> dev-security-policy  wrote:
>>> RFC 5280 section 7.2 and the associated IDNA RFC requires that 
>>> Internationalized Domain Names are normalized before encoding to punycode.
>>>
>>> Let’s Encrypt appears to have issued at least three certificates that have 
>>> at least one dnsName without the proper Unicode normalization applied.
>>>
>>> It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) 
>>> requires normalization form KC, but RFC 5891 which replaces RFC 3491 
>>> requires normalization form C. I believe that the BRs and/or RFC 5280 
>>> should be updated to reference RFC 5890 and by extension RFC 5891 instead.
>>
>> I did some reading on Unicode normalization today, and it strongly
>> appears that any string that has been normalized to normalization form
>> KC is by definition also in normalization form C.  Normalization is
>> idempotent, so doing toNFKC(toNKFC()) will result in the same string
>> as just doing toNFKC() and toNFC(toNFC()) is the same as toNFC().
>> Additionally toNFKC is the same as toNFC(toK()).
>>
>> This means that checking that a string matches the result of
>> toNFC(string) is a valid check regardless of whether using the 349* or
>> 589* RFCs.  It does mean that Certlint will not catch strings that are
>> in NFC but not in NFKC.
>>
>> Thanks,
>> Peter
>>
>> P.S. I've yet to find a registered domain name not in NFC, and that
>> includes checking every name in the the zone files for all ICANN gTLDs
>> and a few ccTLDs
> 
> Hi,
> I have an example international domain that is NFC but not NFKC, 
> "xn--ttt-8fa.pumesa.com" (this is a fake domain and my focus is on the 
> general pattern).
> The pattern that will cause a domain to be NFC but not NFKC in Golang is: 
> "xn--" followed by any same three letters followed by a single "-" followed 
> by any single digit number followed by "fa"; now I know this pattern doesn't 
> describe real unicode, however the behavior in the programming language is 
> curious (below).
> The pattern described above causes strings to be NFC positive but not NFKC in 
> Golang; furthermore, I ran a few tests using Golang (version go1.10.3 darwin) 
> and Java (version "1.8.0_60") and here is the key parts of the code I used:
> 1) Golang (Used "ToUnicode" to mimic how Zlint tests):
> package main
> import (
> "fmt"
> "golang.org/x/net/idna"
> "golang.org/x/text/unicode/norm"
> )
> func main(){
>   str := "xn--xxx-7fa.pumesa.com"
>   punycode,err := idna.ToUnicode(str)
>   if err != nil {
>   fmt.Println(err)
>   }
>   fmt.Println("Is NFC ", norm.NFC.IsNormalString(punycode))
>   fmt.Println("Is NFKC ", norm.NFKC.IsNormalString(punycode))
> }
> 
> The last NFKC check is what causes Zlint to throw an error, stating that the 
> unicode is not in compliance, seems that Zlint needs to be updated to follow 
> the latest BR (RFC 5891), meaning check if the unicode in question is NFC 
> compliant rather than NFKC? 
> 
> Below is something even more interesting.
> 
> 2) Java:
> import java.net.IDN;
> import java.text.Normalizer;
> public class Main{
> public static void main(String args[]){
>   String cn = "xn--www-0xx.pumesa.com";
>   String punycode = IDN.toASCII(cn);
> //punycode = IDN.toUnicode(punycode);
> System.out.println("is NFC " + Normalizer.isNormalized(punycode, 
> Normalizer.Form.NFC));
>   System.out.println("is NFKC " + Normalizer.isNormalized(punycode, 
> Normalizer.Form.NFKC));
> }
> }
> 
> Per Oracle doc, java.net.IDN.toASCII conforms with RFC 3490, and it throws no 
> error, this can be double checked within the language by converting the 
> punycode back to Unicode, both print statements return true.
> 
> So to reiterate, the two main questions are:
> 1) Should there be a discussion about why Oracle Java and Golang don't agree 
> on whether this pattern causes unicode to be NFKC compliant?
> The potential impact is that results obtained from a Java system may not be 
> Zlint compliant.
> 2) Should Zlint be updated to the latest BR (RFC 5891) regardless of question 
> #1?

Probably. However, please be aware that the change from RFC 3490 (IDNA)
to RFC 5891 (IDNA2008) involved more than just a change from Unicode
normalization form C to Unicode normalization form KC.

Also relevant:

https://tools.ietf.org/html/rfc8399

Peter



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Peter Saint-Andre via dev-security-policy]

On 6/1/18 10:04 AM, Ryan Sleevi via dev-security-policy wrote:
> On Fri, Jun 1, 2018 at 9:14 AM, Peter Kurrasch via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Security can be viewed as a series of AND's that must be satisfied in
>> order to conclude "you are probably secure". For example, when you browse
>> to an important website, make sure that "https" is used AND that the domain
>> name looks right  AND that a "lock icon" appears in the UI AND, if the site
>> uses EV certs, that the name of the organization seems correct. Failing any
>> of those, stop immediately; if all of them hold true, you are probably fine.
>>
> 
> Note that research has shown that your first, second, third, and fourth
> options are all unreasonable requests of humans trying to be productive.
> 
> That is, https is unnecessarily confusing, "the domain looks right" is an
> unreasonable task (might as well say "Make sure the fabardle is boijoing"
> when presenting domains), and lock icons positive indicator is unnecessary
> hostile. And that's before we get to EV certs (are you saying I shouldn't
> do business with KLM?)
> 
> So basically, all four steps are unreasonable to determine you're fine :)

Yes, it's a shame that we technologists have abjectly failed at
producing usable security.

However, given the mess we've made of things, we can at least do our
best to protect protect users with the weak and faulty mechanisms we've
created (and work to create better ones). What policies are appropriate
for organizational names in certificates?

Peter




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Peter Saint-Andre via dev-security-policy]

On 5/31/18 2:38 PM, James Burton via dev-security-policy wrote:
> I posted this also on the CAB Forum validation mailing list but I think
> it's worthy of discussion on both lists.
> 
> 
> I recently incorporated the company named ";", see:
> https://beta.companieshouse.gov.uk/company/11363219. This company compiles 
> with
> the both the "Companies Act 2006" and "The Company, Limited Liability
> Partnership and Business (Names and Trading Disclosures) Regulations 2015".
> 
> 
> Now the current guidelines state that this type of name is not allowed due
> to regulation 7.1.4.2.2 (j). I misinterpret this regulation and I thought
> that because this name is complete and incorporated that the name should be
> allowed in the O field. I was corrected by forum member.
> 
> 
> This is wrong and should be changed to allow all types of legally
> incorporated company names to get certificates. I understand this
> doesn't fit any of the standard company name profiles you've seen but this
> company name can be used in practice  and I can think of many business
> types that would love this type of name.

We can also think of many business types (e.g., scammers) that would
love to have names like ⒶⓅⓅⓁⒺ but that doesn't mean it's smart to issue
certificates with such names. The authorities who approve of company
names don't necessarily have certificate handling in mind...

Just my centigram of silver...

Peter



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Transforming a trade name into ASCII in the O field of an OV cert

[Peter Saint-Andre via dev-security-policy]

On 4/24/18 2:47 PM, Henri Sivonen via dev-security-policy wrote:
> On Tue, Apr 24, 2018 at 11:03 PM, cbonnell--- via dev-security-policy
>  wrote:
>> On Tuesday, April 24, 2018 at 4:33:24 PM UTC-4, Henri Sivonen wrote:
>>> On Tue, Apr 24, 2018 at 10:18 PM, Jeremy Rowley via
>>> dev-security-policy  wrote:
 That is correct. We use transliteration of non-latin names through a system
 recognized by ISO per Appendix D(1)(3)
>>>
>>> But "Säästöpankkiliitto osk" is not a non-Latin name! (It is a
>>> non-ASCII name.) Also, no such transliteration is applied to
>>> "Ålandsbanken Abp", so evidently there's no technical necessity for
>>> transforming the name.
>>>
>>> Clearly, D(1) does not apply (the name is not non-Latin). D(2) doesn't
>>> make sense (it doesn't make sense to Romanize a Latin-script name).
>>> D(3) is about *translated* names (the organization has translated
>>> names [in Swedish and in English], but the name on the certificate is
>>> neither of those).
>>>
>>> --
>>> Henri Sivonen
>>> hsivo...@hsivonen.fi
>>> https://hsivonen.fi/
>>
>> Although the EV Guidelines don’t explicitly state this, I think it’s 
>> reasonable to interpret the EV Guidelines’s use of “Latin characters” as the 
>> characters comprising the ISO basic Latin alphabet 
>> (https://en.wikipedia.org/wiki/ISO basic Latin_alphabet) or the characters 
>> in the Basic Latin Unicode Block 
>> (https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)).
> 
> That's not at all clear from the text of the document. If the document
> means Basic Latin, it ought to say so instead of saying Latin.

As noted in RFC 6365:

  "Latin characters" is a not-precise term for characters
  historically related to ancient Greek script as modified in the
  Roman Republic and Empire and currently used throughout the world.
  

  The base Latin characters are a subset of the ASCII repertoire and
  have been augmented by many single and multiple diacritics and
  quite a few other characters.  ISO/IEC 10646 encodes the Latin
  characters in including ranges U+0020..U+024F and U+1E00..U+1EFF.

  Because "Latin characters" is used in different contexts to refer
  to the letters from the ASCII repertoire, the subset of those
  characters used late in the Roman Republic period, or the
  different subset used to write Latin in medieval times, the entire
  ASCII repertoire, all of the code points in the extended Latin
  script as defined by Unicode, and other collections, the term
  should be avoided in IETF specifications when possible.
  Similarly, "Basic Latin" should not be used as a synonym for
  "ASCII".

Peter




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Peter Saint-Andre via dev-security-policy]

On 4/12/18 9:17 PM, jomo via dev-security-policy wrote:
>> I doubt Let's Encrypt would issue for paypal.any_valid_tld even if CAA would
>> permit.
> 
> https://paypal.cologne :)

There's nothing like an existence proof to get one's attention. :-)

Peter

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Peter Saint-Andre via dev-security-policy]

On 2/27/18 4:15 PM, Wayne Thayer wrote:
> On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via
> dev-security-policy <dev-security-policy@lists.mozilla.org
> <mailto:dev-security-policy@lists.mozilla.org>> wrote:
> 
> On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On Tue, 27 Feb 2018 09:20:33 -0700
> > Wayne Thayer via dev-security-policy
> > <dev-security-policy@lists.mozilla.org
> <mailto:dev-security-policy@lists.mozilla.org>> wrote:
> >
> >> This capability existed in the legacy Firefox extension system that
> >> was deprecated last year. It was used to implement stricter security
> >> mechanisms (e.g. CertPatrol) and to experiment with new mechanisms
> >> such as Certificate Transparency and DANE.
> >
> > Wouldn't be a good compromise to say: Extensions can downgrade
> > security, but they can't upgrade it?
> 
> 
> In the bug I referenced as [2], people said that they specifically need
> to be able to override "negative" certificate validation decisions, so
> they may not see this as a compromise. I think an example would be a
> site serving a self-signed certificate for a DANE add-on to validate.
> 
> 
> Don't you mean the other way around? Otherwise, we're creating a
> powerful footgun.
> 
> I assume that by "downgrade", Hanno meant "change the UI to indicate a
> bad cert" and by "upgrade" he meant "indicate a valid cert in the UI
> when validation has failed".

OK, we're all in agreement but using opposite terminology. :)

Peter



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Peter Saint-Andre via dev-security-policy]

On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> Hi,
> 
> On Tue, 27 Feb 2018 09:20:33 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
> 
>> This capability existed in the legacy Firefox extension system that
>> was deprecated last year. It was used to implement stricter security
>> mechanisms (e.g. CertPatrol) and to experiment with new mechanisms
>> such as Certificate Transparency and DANE.
> 
> Wouldn't be a good compromise to say: Extensions can downgrade
> security, but they can't upgrade it?

Don't you mean the other way around? Otherwise, we're creating a
powerful footgun.

Peter




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy