On Mon, Mar 25, 2019 at 5:30 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> My ultimate intent was to try to formulate a way in which GRCA could
> provide certificates for the applications that they're having to support
> for their clients today
On 25/03/2019 22:29, Matthew Hardeman wrote:
On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
While it may be true that the certificates in question do not contain
SANs, unfortunately, the certificates may still be trusted for
On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> While it may be true that the certificates in question do not contain
> SANs, unfortunately, the certificates may still be trusted for SSL since
> they do not have EKUs.
>
> For an
On 25/3/2019 10:48 μ.μ., Wayne Thayer via dev-security-policy wrote:
I agree with Ryan on this. From a policy perspective, we should be
encouraging [and eventually requiring] EKU constraints, not making it
easier to exclude them.
I was merely copying parts of the existing policy related to
I agree with Ryan on this. From a policy perspective, we should be
encouraging [and eventually requiring] EKU constraints, not making it
easier to exclude them.
On Mon, Mar 25, 2019 at 1:03 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> While it may be
While it may be true that the certificates in question do not contain SANs,
unfortunately, the certificates may still be trusted for SSL since they do not
have EKUs.
For an example see "The most dangerous code in the world: validating SSL
certificates in non-browser software" which is
On 17/3/2019 1:54 π.μ., Matthew Hardeman via dev-security-policy wrote:
While sending a message that non-compliance could result in policy change
is generally a bad idea, I did notice something about the profile of the
non-compliant certificate which gave me pause:
None of the example
While sending a message that non-compliance could result in policy change
is generally a bad idea, I did notice something about the profile of the
non-compliant certificate which gave me pause:
None of the example certificates which were provided include a SAN
extension at all.
Today, no valid
I think answers to the following questions might be helpful:
1. What software / types of software are being utilized which would give
compatibility issues? What is the validation logic of those applications /
systems?
2. If these certificates don't have a purpose known to or respected by the
In bug 1523221 [1], GRCA (Government of Taiwan) has responded to a
misissuance report by stating that the certificates in question are not
intended for serverAuth or emailProtection. However, our policy applies to
certificates **capable** of being used for serverAuth or emailProtection,
including
10 matches
Mail list logo
