Re: PrintableString, UTF8String, and RFC 5280

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>I don't think the hyperbole helps here.

It wasn't hyperbole, it was extreme surprise.  When someone told me about this
I couldn't believe it was still happening after the massive amount of
publicity it got at the time, so it was more a giant "WTF?!??" than anything
else.

Other CA certs with this issue include further audited and (in some cases) EV-
approved certs, all from Microsoft:

https://crt.sh/?id=988218851=x509lint,zlint,cablint
https://crt.sh/?id=988140328=zlint,x509lint,cablint
https://crt.sh/?id=988215004=zlint,cablint,x509lint
https://crt.sh/?id=988137612=x509lint,cablint
https://crt.sh/?id=1197076917=x509lint,cablint
https://crt.sh/?id=1197067049=x509lint,cablint
https://crt.sh/?id=1197079848=x509lint,cablint
https://crt.sh/?id=1197075787=x509lint,cablint
https://crt.sh/?id=554380367=x509lint
https://crt.sh/?id=918173942=x509lint,cablint

I don't know who trust what where, but Chrome at least seems to trust these
two:

https://crt.sh/?id=554380367=x509lint
https://crt.sh/?id=918173942=x509lint,cablint

>It's probably better to start a new thread if you'd like to talk about it 
>further.

Sure, it just came to mind when I saw this thread, which is why I posted it
here.

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

Re: PrintableString, UTF8String, and RFC 5280

[Ryan Sleevi via dev-security-policy]

On Wed, Nov 20, 2019 at 10:54 PM Peter Gutmann 
wrote:

> Ryan Sleevi  writes:
>
> >Do you believe it’s still applicable in the Web PKI of the past decade?
>
> Yes, the specific cert I referenced is current valid and passed WebTrust
> and
> EV audits.
>

"Passed" is... a bit misleading as to the (limited) assurance WebTrust (and
audits in general) provide, or more aptly, misleading as to how they work :)

But I agree, this is concerning.


> >If you could link to the crt.sh entry, that might be easier.
>
> Here's the Microsoft one I mentioned:
>
>   Microsoft RSA Root Certificate Authority 2017
>
>   https://crt.sh/?id=988218851=x509lint,zlint,cablint


Excellent! Thanks


> There are numerous others.  This particular one isn't just a CA cert, it's
> a
> root cert.
>
> >It could be that you’re referencing the use of BMPString
>
> I'm just quoting X509lint:
>
>ERROR: URL contains a null character
>
> Given that this was exposed as a major security hole ten years ago, I was
> surprised when someone notified me that these things exist, and that no-one
> seems to have done anything about it.
>

I don't think the hyperbole helps here. You can see from the long list of
incidents at https://wiki.mozilla.org/CA/Incident_Dashboard that we take
incidents seriously as they're brought to attention, and have spent
considerable effort in making sure that anyone finding anything odd has a
clear path to reporting and a clear path to trying to resolve these issues
systematically. You can also see linters appropriately warning about this -
and the expectation for CAs to be monitoring such certificates for errors.

As to the incident, I'm showing this root only trusted by Microsoft at
present - https://crt.sh/?caid=108560
 .
https://bugzilla.mozilla.org/show_bug.cgi?id=1582254 has not yet included
them in the Mozilla store, so you should feel free to add comments there.

I don't think there's anything to conclude "nothing is being done about
it", but you can also see, from the original message and the discussion on
the bug, that no, we did not talk about this topic. It's probably better to
start a new thread if you'd like to talk about it further.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PrintableString, UTF8String, and RFC 5280

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>Do you believe it’s still applicable in the Web PKI of the past decade?

Yes, the specific cert I referenced is current valid and passed WebTrust and
EV audits.

>If you could link to the crt.sh entry, that might be easier.

Here's the Microsoft one I mentioned:

  Microsoft RSA Root Certificate Authority 2017

  https://crt.sh/?id=988218851=x509lint,zlint,cablint

There are numerous others.  This particular one isn't just a CA cert, it's a
root cert.

>It could be that you’re referencing the use of BMPString

I'm just quoting X509lint:

   ERROR: URL contains a null character

Given that this was exposed as a major security hole ten years ago, I was
surprised when someone notified me that these things exist, and that no-one
seems to have done anything about it.

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

Re: PrintableString, UTF8String, and RFC 5280

[Ryan Sleevi via dev-security-policy]

On Wed, Nov 20, 2019 at 9:48 PM Peter Gutmann 
wrote:

> Ryan Sleevi via dev-security-policy 
> writes:
>
> >In https://bugzilla.mozilla.org/show_bug.cgi?id=1593814 , Rob Stradling,
> >Jeremy Rowley, and I started discussing possible steps that might be
> taken to
> >prevent misencoding strings in certificates
>
> Is there any official position on strings that have completely invalid
> encodings like embedded NULL characters in them (presumably in memoriam of
> the
> Kaminsky/Marlinspike certificate-spoofing bug) as one of Microsoft's CA
> certificates among numerous others do?


I’m not sure I understand the link to the discussion and why you’re
bringing it up? Do you believe it’s still applicable in the Web PKI of the
past decade?

I ask, because this is already addressed rather extensively, and has been
for some time, within linters, and since at least 2012 with respect to the
Baseline Requirements, through the incorporation of RFC 5280, and thus
transitively the incorporation of DNS preferred name syntax.

I’m not sure which of Microsoft’s CAs you’re referring to, so you’d have to
be more precise. Do you mean the publicly trusted certificates? Or
something only trusted on Windows? If you could link to the crt.sh entry,
that might be easier.

It could be that you’re referencing the use of BMPString, which systems
like Active Directory Certificate Services used. Those, being 16-bit code
points, certainly “seemed” like they had embedded NULs, but only if
misinterpreted as 8-bit.

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

Re: PrintableString, UTF8String, and RFC 5280

[Peter Gutmann via dev-security-policy]

Ryan Sleevi via dev-security-policy  
writes:

>In https://bugzilla.mozilla.org/show_bug.cgi?id=1593814 , Rob Stradling,
>Jeremy Rowley, and I started discussing possible steps that might be taken to
>prevent misencoding strings in certificates

Is there any official position on strings that have completely invalid
encodings like embedded NULL characters in them (presumably in memoriam of the
Kaminsky/Marlinspike certificate-spoofing bug) as one of Microsoft's CA
certificates among numerous others do?

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

WebTrust direct URLs to PDF audit statements will be down during site update

[Kathleen Wilson via dev-security-policy]

All,

CPA Canada just informed me that the PDF file URLs that we use in the 
CCADB for WebTrust audits will be down for a while as they perform a 
site update.


You will still be able to access the audit statements via the Seal files 
on the CA websites during this time.


We apologize for the inconvenience that this causes, and I will provide 
updated information as it becomes available.


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

Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

[Wayne Thayer via dev-security-policy]

The last change I am proposing for version 2.7 of the Mozilla Root Store
policy is an update to the minimum versions of audit criteria that we will
accept in audits. I have conferred with the WebTrust Task Force and was
informed that we can update the minimum version requirements for audit
statements received after December 2019 as follows:

WebTrust for CA – instead of v2.0 use v2.2
WebTrust for BL+NSR – instead of v2.2 use v2.4.1
WebTrust for EVSSL – instead of v1.6.0 use v1.6.8

I asked the same question to ETSI representatives and was told that the
following changes are appropriate:

ETSI EN 319 411-1 - instead of v1.1.1 use v1.2.2
ETSI EN 319 411-2 - instead of v2.1.1 use v2.2.2

I have made these changes at
https://github.com/mozilla/pkipolicy/commit/f605b39ccd9d1000ecebbfc028ab99aafae73d33
(I also update the links in a later commit)

This is https://github.com/mozilla/pkipolicy/issues/197

I will greatly appreciate everyone's feedback - especially from any CAs or
auditors for which these changes may cause problems.

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

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

[Wayne Thayer via dev-security-policy]

On Thu, Nov 14, 2019 at 3:24 PM Wayne Thayer  wrote:

> On Fri, Nov 8, 2019 at 12:06 PM Ryan Sleevi  wrote:
>
>>
>> On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> A few more questions have come up about this change:
>>>
>>> * Since mozilla::pkix doesn't currently support the RSA-PSS encodings,
>>> why
>>> would we include them in our policy?
>>>
>>
>> They were included for completeness sake, as neither Mozilla Policy nor
>> the BRs presently forbid them.
>>
>> I'm much in favor of not permitting them, but since the current
>> restriction on RSA keys does not restrict the signature algorithms used, we
>> wanted to make sure the combinations were suitable.
>>
>>
>
> I understand the point that including the RSA-PSS encodings does not
> change the literal meaning of the current policy, but it does imply that
> Mozilla supports these encodings when in fact NSS does not. We could
> resolve this by removing the RSA-PSS encodings or by adding a note stating
> that Firefox doesn't currently support them. I prefer adding the note,
> since Firefox could add support [1] for RSA-PSS much more quickly that this
> policy is typically updated. I propose the following:
>
> Note: as of version 70, RSASSA-PSS encodings are not supported by Firefox.
> (with a link to [1])
>
>
I've gone ahead and made this change in the 2.7 branch of the policy:
https://github.com/mozilla/pkipolicy/commit/320d3a47c655c5b49f6465d9446ceea85be96d4b

- Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1088140
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

PrintableString, UTF8String, and RFC 5280

[Ryan Sleevi via dev-security-policy]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1593814 , Rob Stradling,
Jeremy Rowley, and I started discussing possible steps that might be taken
to prevent misencoding strings in certificates, and it seemed appropriate
to shift this to a more general m.d.s.p. discussion, rather than solely on
the bug. Hopefully folks know I'm all in favor of discussing systemic
remediations on list, and would love to see more of that, as they hopefully
get wider attention.

The context is DirectoryString, which is a string type that supports many
different encodings, as it's a CHOICE. Such fields are generally left up to
a CA's discretion - after all, CHOICE exists to, well, give a choice.

DirectoryString comes to us from X.500 and related; a carryover from the
Directory Access Protocol and it's more well-loved sibling, the Lightweight
Directory Access Protocol.

When RFC 2459 was specified, it tried to get all CAs to converge on a
single type, to reduce variance, confusion, and complexity. It introduced a
normative MUST that, if issued after 2003-12-31, CAs MUST use UTF8String,
and until then, should try to minimize variance using a set of rules. RFC
3280, published 2002, continued that sunset. However, when RFC 5280 was
published in 2008, it removed that sunset, and basically left the
compatibility language in from previous versions. The reasons should be
obvious: RFCs are signs, not cops, and unless/until someone enforces
compliance with RFCs, then it's really up to implementors.

On the related bug, one of the suggestions was to reduce the risk of
PrintableString misencoding, CAs can and should align on using UTF8String
for encoding DirectoryString types. UTF8String, while requiring valid UTF-8
code points, is significantly more flexible in what it can represent.

Rob Stradling helpfully, and rightfully, pointed out that CAs would still
need to maintain code to correctly encode PrintableStrings. That's because
several attributes in the Subject - such as countryName and serialNumber -
still use PrintableString.

However, I think Rob's point emphasizes the risks, and the mitigations. In
my view, the big risk is that CAs are encouraged to adopt the customer's
preferred spelling or localization for entities like organization,
organizationalUnit, or locality - fields which are DirectoryStrings - and
thus prone to misencoding, especially if the CA lifts the encoded values
from CSRs. Because the BRs and EVGs don't prohibit adopting the customer's
preferred values, so long as they're validated appropriate (e.g. in a QGIS
or QIIS) as valid forms, this remains a risk.

Related to the issue from DigiCert, I (and colleagues at other root
programs) have seen issues in how CAs encode their certificate issuer names
and subject names. For example, we've seen CAs use one string form in the
Subject, and a different string form in Issuer, despite the language in RFC
4.1.2.6 regarding the same encoding. Without wanting to go into a full
discussion there about the encoding, I raise it as another issue where
aligning on a common choice for DirectoryString substantially reduces the
risk of issues.

I'm curious to hear from more CAs, and I suspect Rob will have more
excellent points to the contrary, but thought it best to consider
discussion on-list rather than on-bug :)

Put differently: Are there reasons to continue to use PrintableString for
newly issued certificates, and CAs? There are risks to continuing to allow
flexibility, and complexities in getting that flexibility right, so
reducing that complexity is one of the ways we can significantly reduce
risk.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

[Kathleen Wilson via dev-security-policy]

On 11/19/19 4:59 PM, Kathleen Wilson wrote:
Note: I will add a report to 
wiki.mozilla.org/CA/Intermediate_Certificates to list all of  the 
intermediate certificates that have been added to OneCRL and their 
revocation status. This will enable the CA Community to identify which 
certificates have been added to OneCRL but are not actually revoked.


The report is available now.

https://wiki.mozilla.org/CA/Intermediate_Certificates
~~
The following reports list the intermediate certificates that have been 
added to OneCRL, and their revocation status as indicated by the CA in 
the CCADB.


Intermediate CA Certificates in OneCRL (HTML)
Intermediate CA Certificates in OneCRL (CSV)
~~

Direct links:
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsInOneCRLReport
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsInOneCRLReportCSV

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