Re: [FORGED] Re: Other Curves

[Peter Gutmann]

Ryan Sleevi  writes:

>Current (and presently proposed) Mozilla policy does not allow them. Nor are
>they supported in Mozilla NSS anymore (and their previous support was not one
>you should use for security-critical purposes). Nor are they supported in
>other UAs.

I should point out that, for the Brainpool curves, pretty much every
significant open-source SSL library had support for them implemented within
days, in some cases within hours, of the required RFC being published.  That
was driven by Snowden, but I've never seen an RFC adopted that quickly before.

(It helped that the Brainpool curves are absolutely trivial to implement, just
copy across the hex values into your table of curves).

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

Issuer field in the CRL should be byte-for-byte equivalent with that in cert

[Kathleen Wilson]

All,

I've added another Potentially Problematic Practice, as follows.

https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL
The encoding of the Issuer field in the CRL should be byte-for-byte equivalent 
with the encoding of the Issuer in the certificate; that is, using the exact 
same string types and field contents. The specs (RFC 2459, RFC 3280, RFC 5280) 
permit them to mismatch, but that causes compatibility issues with various 
clients -- in such cases client software might not find the entry for the 
revoked certificate in the CRL. 

As always, I will appreciate your thoughtful and constructive feedback.

We ran into this situation several times while adding entries to OneCRL for 
revoked intermediate certificates, because our script pulled the data from the 
CAs' CRLs where possible.

We have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1330968 to update 
the OneCRL client to be encoding agnostic when doing the Issuer comparisons.

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

Re: Other Curves

[Peter Bowen]

https://tools.ietf.org/html/draft-ietf-curdle-pkix-03 needs to move
forward first. It is currently in working group last call.
https://tools.ietf.org/html/rfc8032 is now published, which replaces
I-D.irtf-cfrg-eddsa, so that removes the last dangling reference from
curdle-pkix.

We also need to sort out the HSM situation.  I'll bet that we could
lure some HSM vendors to meet with CAs at some upcoming industry event
where we can express our interests to them :)


On Wed, Feb 1, 2017 at 3:06 PM, Jeremy Rowley
 wrote:
> Works for me. Any idea on when Mozilla is planning to permit Curve22519 and 
> Curve448? I’d like to plan for that date.
>
>
>
> From: Richard Barnes [mailto:rbar...@mozilla.com]
> Sent: Wednesday, February 1, 2017 4:04 PM
> To: Jeremy Rowley 
> Cc: Hanno Böck ; r...@sleevi.com; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Other Curves
>
>
>
> Unfortunately, despite the Bitcoin community's enthusiasm, secp256k1 has very 
> bad side-channel properties:
>
> https://eprint.iacr.org/2014/161.pdf
> https://bugzilla.mozilla.org/show_bug.cgi?id=1051509
>
> Overall, I agree with Ryan that proliferation in this space is to be avoided. 
>  I expect that the only real non-NIST algorithm we will expect to support in 
> the near term is EdDSA.
>
> --Richard
>
>
>
>
>
> On Wed, Feb 1, 2017 at 2:58 PM, Jeremy Rowley   > wrote:
>
> I think I should mention that I suggested secp256k1 for blockchain reasons...
>
> -Original Message-
> From: Hanno Böck [mailto:ha...@hboeck.de  ]
> Sent: Wednesday, February 1, 2017 3:52 PM
> To: Jeremy Rowley   >
> Cc: r...@sleevi.com  ; 
> mozilla-dev-security-pol...@lists.mozilla.org 
> 
> Subject: Re: Other Curves
>
> On Wed, 1 Feb 2017 22:38:54 +
> Jeremy Rowley  
> > wrote:
>
>> Some of these curves are considered much better than the NIST curves
>> (well, that’s what I’ve read anyway).
>
> Overall they have mostly the same weaknesses than the NIST curves.
> There are differences in detail, but it really doesn't justify introducing a 
> lot of variety in the ecosystem. But I have a pretty good idea where that 
> hearsay comes from, and I'm pretty sure it has little to do with security.
>
> The modern curves like Curve25519 and Curve448 avoid many of the security 
> pitfalls of older curves. If you want more secure curves look at them and 
> push standards forward so they can be used within X.509.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de 
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
>
> ___
> 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: Other Curves

[Ryan Sleevi]

Perhaps I might suggest "No earlier than an RFC defining how they're used
in certificates is approved"? :)

Is there a reason you wouldn't just bring this up in the Forum? We (Google)
would be happy to support a ballot - once the RFC has reached the consensus
process - for allowing it for leaves. For intermediates/roots, the most
recent Forum F2F spent a considerable amount of time discussing the
challenges and preconditions towards allowing such a thing, and I'm sure
there will be more discussion next month.

On Wed, Feb 1, 2017 at 3:06 PM, Jeremy Rowley 
wrote:

> Works for me. Any idea on when Mozilla is planning to permit Curve22519
> and Curve448? I’d like to plan for that date.
>
>
>
> *From:* Richard Barnes [mailto:rbar...@mozilla.com]
> *Sent:* Wednesday, February 1, 2017 4:04 PM
> *To:* Jeremy Rowley 
> *Cc:* Hanno Böck ; r...@sleevi.com;
> mozilla-dev-security-pol...@lists.mozilla.org
> *Subject:* Re: Other Curves
>
>
>
> Unfortunately, despite the Bitcoin community's enthusiasm, secp256k1 has
> very bad side-channel properties:
>
> https://eprint.iacr.org/2014/161.pdf
> https://bugzilla.mozilla.org/show_bug.cgi?id=1051509
>
> Overall, I agree with Ryan that proliferation in this space is to be
> avoided.  I expect that the only real non-NIST algorithm we will expect to
> support in the near term is EdDSA.
>
> --Richard
>
>
>
>
>
> On Wed, Feb 1, 2017 at 2:58 PM, Jeremy Rowley 
> wrote:
>
> I think I should mention that I suggested secp256k1 for blockchain
> reasons...
>
> -Original Message-
> From: Hanno Böck [mailto:ha...@hboeck.de]
> Sent: Wednesday, February 1, 2017 3:52 PM
> To: Jeremy Rowley 
> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Other Curves
>
> On Wed, 1 Feb 2017 22:38:54 +
> Jeremy Rowley  wrote:
>
> > Some of these curves are considered much better than the NIST curves
> > (well, that’s what I’ve read anyway).
>
> Overall they have mostly the same weaknesses than the NIST curves.
> There are differences in detail, but it really doesn't justify introducing
> a lot of variety in the ecosystem. But I have a pretty good idea where that
> hearsay comes from, and I'm pretty sure it has little to do with security.
>
> The modern curves like Curve25519 and Curve448 avoid many of the security
> pitfalls of older curves. If you want more secure curves look at them and
> push standards forward so they can be used within X.509.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
>
> ___
> 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: Other Curves

[Jeremy Rowley]

Works for me. Any idea on when Mozilla is planning to permit Curve22519 and 
Curve448? I’d like to plan for that date.

 

From: Richard Barnes [mailto:rbar...@mozilla.com] 
Sent: Wednesday, February 1, 2017 4:04 PM
To: Jeremy Rowley 
Cc: Hanno Böck ; r...@sleevi.com; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Other Curves

 

Unfortunately, despite the Bitcoin community's enthusiasm, secp256k1 has very 
bad side-channel properties:

https://eprint.iacr.org/2014/161.pdf
https://bugzilla.mozilla.org/show_bug.cgi?id=1051509

Overall, I agree with Ryan that proliferation in this space is to be avoided.  
I expect that the only real non-NIST algorithm we will expect to support in the 
near term is EdDSA.

--Richard

 

 

On Wed, Feb 1, 2017 at 2:58 PM, Jeremy Rowley  > wrote:

I think I should mention that I suggested secp256k1 for blockchain reasons...

-Original Message-
From: Hanno Böck [mailto:ha...@hboeck.de  ]
Sent: Wednesday, February 1, 2017 3:52 PM
To: Jeremy Rowley  >
Cc: r...@sleevi.com  ; 
mozilla-dev-security-pol...@lists.mozilla.org 
 
Subject: Re: Other Curves

On Wed, 1 Feb 2017 22:38:54 +
Jeremy Rowley  > 
wrote:

> Some of these curves are considered much better than the NIST curves
> (well, that’s what I’ve read anyway).

Overall they have mostly the same weaknesses than the NIST curves.
There are differences in detail, but it really doesn't justify introducing a 
lot of variety in the ecosystem. But I have a pretty good idea where that 
hearsay comes from, and I'm pretty sure it has little to do with security.

The modern curves like Curve25519 and Curve448 avoid many of the security 
pitfalls of older curves. If you want more secure curves look at them and push 
standards forward so they can be used within X.509.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de  
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


___
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: Other Curves

[Kurt Roeckx]

On Wed, Feb 01, 2017 at 11:51:48PM +0100, Hanno Böck wrote:
> On Wed, 1 Feb 2017 22:38:54 +
> Jeremy Rowley  wrote:
> 
> > Some of these curves are considered much better than the NIST curves
> > (well, that’s what I’ve read anyway).
> 
> Overall they have mostly the same weaknesses than the NIST curves.
> There are differences in detail, but it really doesn't justify
> introducing a lot of variety in the ecosystem. But I have a pretty good
> idea where that hearsay comes from, and I'm pretty sure it has little
> to do with security.
> 
> The modern curves like Curve25519 and Curve448 avoid many of the
> security pitfalls of older curves. If you want more secure curves look
> at them and push standards forward so they can be used within X.509.

This is mostly what I wanted to say.


Kurt

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

Re: Other Curves

[Richard Barnes]

Unfortunately, despite the Bitcoin community's enthusiasm, secp256k1 has
very bad side-channel properties:

https://eprint.iacr.org/2014/161.pdf
https://bugzilla.mozilla.org/show_bug.cgi?id=1051509

Overall, I agree with Ryan that proliferation in this space is to be
avoided.  I expect that the only real non-NIST algorithm we will expect to
support in the near term is EdDSA.

--Richard


On Wed, Feb 1, 2017 at 2:58 PM, Jeremy Rowley 
wrote:

> I think I should mention that I suggested secp256k1 for blockchain
> reasons...
>
> -Original Message-
> From: Hanno Böck [mailto:ha...@hboeck.de]
> Sent: Wednesday, February 1, 2017 3:52 PM
> To: Jeremy Rowley 
> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Other Curves
>
> On Wed, 1 Feb 2017 22:38:54 +
> Jeremy Rowley  wrote:
>
> > Some of these curves are considered much better than the NIST curves
> > (well, that’s what I’ve read anyway).
>
> Overall they have mostly the same weaknesses than the NIST curves.
> There are differences in detail, but it really doesn't justify introducing
> a lot of variety in the ecosystem. But I have a pretty good idea where that
> hearsay comes from, and I'm pretty sure it has little to do with security.
>
> The modern curves like Curve25519 and Curve448 avoid many of the security
> pitfalls of older curves. If you want more secure curves look at them and
> push standards forward so they can be used within X.509.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> ___
> 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: Other Curves

[Jeremy Rowley]

I think I should mention that I suggested secp256k1 for blockchain reasons...

-Original Message-
From: Hanno Böck [mailto:ha...@hboeck.de] 
Sent: Wednesday, February 1, 2017 3:52 PM
To: Jeremy Rowley 
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Other Curves

On Wed, 1 Feb 2017 22:38:54 +
Jeremy Rowley  wrote:

> Some of these curves are considered much better than the NIST curves 
> (well, that’s what I’ve read anyway).

Overall they have mostly the same weaknesses than the NIST curves.
There are differences in detail, but it really doesn't justify introducing a 
lot of variety in the ecosystem. But I have a pretty good idea where that 
hearsay comes from, and I'm pretty sure it has little to do with security.

The modern curves like Curve25519 and Curve448 avoid many of the security 
pitfalls of older curves. If you want more secure curves look at them and push 
standards forward so they can be used within X.509.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


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: Other Curves

[Jeremy Rowley]

I'd be happy with those as alternatives to SuiteB. They aren't requested as 
often as the others, but enough that we could push customers worried about 
using a NIST curve that way (assuming I can get the HSM dealers to support the 
curve). 

-Original Message-
From: Hanno Böck [mailto:ha...@hboeck.de] 
Sent: Wednesday, February 1, 2017 3:52 PM
To: Jeremy Rowley 
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Other Curves

On Wed, 1 Feb 2017 22:38:54 +
Jeremy Rowley  wrote:

> Some of these curves are considered much better than the NIST curves 
> (well, that’s what I’ve read anyway).

Overall they have mostly the same weaknesses than the NIST curves.
There are differences in detail, but it really doesn't justify introducing a 
lot of variety in the ecosystem. But I have a pretty good idea where that 
hearsay comes from, and I'm pretty sure it has little to do with security.

The modern curves like Curve25519 and Curve448 avoid many of the security 
pitfalls of older curves. If you want more secure curves look at them and push 
standards forward so they can be used within X.509.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


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: Other Curves

[Hanno Böck]

On Wed, 1 Feb 2017 22:38:54 +
Jeremy Rowley  wrote:

> Some of these curves are considered much better than the NIST curves
> (well, that’s what I’ve read anyway).

Overall they have mostly the same weaknesses than the NIST curves.
There are differences in detail, but it really doesn't justify
introducing a lot of variety in the ecosystem. But I have a pretty good
idea where that hearsay comes from, and I'm pretty sure it has little
to do with security.

The modern curves like Curve25519 and Curve448 avoid many of the
security pitfalls of older curves. If you want more secure curves look
at them and push standards forward so they can be used within X.509.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Other Curves

[Jeremy Rowley]

That’s a pretty vague argument against adding some curves. With that logic, 
we’d never have moved away from MD5 hash as moving away would have disrupted 
the ecosystem…  

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Wednesday, February 1, 2017 3:46 PM
To: Jeremy Rowley 
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Other Curves

 

 

 

On Wed, Feb 1, 2017 at 2:38 PM, Jeremy Rowley  > wrote:

Some of these curves are considered much better than the NIST curves (well, 
that’s what I’ve read anyway). With how many new curves there are (many with an 
international flavor), it’d be nice if Mozilla considered some of the new 
curves and added them if appropriate. Brainpool is supported in RFCs, HSMs, and 
in applications.

 

That's more of a compelling argument against than for; similar to the 
discussions for algorithms like SM2 or IDEA or Camellia in TLS.

 

As Adam Langley eloquently captured in 
https://bugs.chromium.org/p/chromium/issues/detail?id=442572#c5 "Cipher suites 
are not like Pokémon: the aim isn't to enable every single one." 

 

The same applies to curves

 

The question inevitably is not necessarily one about enforcing Mozilla's view 
of curve strength (or of Google's), but one of considering the ecosystem and 
security impact to their users by promoting/allowing such things.



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: Other Curves

[Ryan Sleevi]

On Wed, Feb 1, 2017 at 2:38 PM, Jeremy Rowley 
wrote:

> Some of these curves are considered much better than the NIST curves
> (well, that’s what I’ve read anyway). With how many new curves there are
> (many with an international flavor), it’d be nice if Mozilla considered
> some of the new curves and added them if appropriate. Brainpool is
> supported in RFCs, HSMs, and in applications.
>

That's more of a compelling argument against than for; similar to the
discussions for algorithms like SM2 or IDEA or Camellia in TLS.

As Adam Langley eloquently captured in
https://bugs.chromium.org/p/chromium/issues/detail?id=442572#c5 "Cipher
suites are not like Pokémon: the aim isn't to enable every single one."

The same applies to curves

The question inevitably is not necessarily one about enforcing Mozilla's
view of curve strength (or of Google's), but one of considering the
ecosystem and security impact to their users by promoting/allowing such
things.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Other Curves

[Jeremy Rowley]

Some of these curves are considered much better than the NIST curves (well, 
that’s what I’ve read anyway). With how many new curves there are (many with an 
international flavor), it’d be nice if Mozilla considered some of the new 
curves and added them if appropriate. Brainpool is supported in RFCs, HSMs, and 
in applications.

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Wednesday, February 1, 2017 3:34 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Other Curves

 

That seems altogether a bad idea for the ecosystem.

 

Current (and presently proposed) Mozilla policy does not allow them. Nor are 
they supported in Mozilla NSS anymore (and their previous support was not one 
you should use for security-critical purposes). Nor are they supported in other 
UAs.

 

I'm sympathetic to the argument that "If they're not used for server certs, 
what's the matter" - but I think there's a reasonable concern for anything a CA 
signs/issues and avoiding ambiguity/risk, and that's something that requires 
considerable amounts of energy.

 

On Wed, Feb 1, 2017 at 2:26 PM, Jeremy Rowley  > wrote:

I know the use of other ECC curves comes up often, but I couldn't recall
where Mozilla landed on using other ECC curves. Requests for secp256k1 and
brainpool curves are increasing rapidly. If Mozilla updated its policy, we
could start using these curves for client certs, even if the baseline
requirements still prohibit them in TLS certs.



Jeremy


___
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: Other Curves

[Jeremy Rowley]

Both preferably, but I’d accept at the EE level. Primarily secp256k1 and 
brainpool, but mostly secp256k1. 

 

From: Richard Barnes [mailto:rbar...@mozilla.com] 
Sent: Wednesday, February 1, 2017 3:35 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Other Curves

 

Do you mean for signing by the CA, or as the key in the EE cert?

 

On Wed, Feb 1, 2017 at 2:26 PM, Jeremy Rowley  > wrote:

I know the use of other ECC curves comes up often, but I couldn't recall
where Mozilla landed on using other ECC curves. Requests for secp256k1 and
brainpool curves are increasing rapidly. If Mozilla updated its policy, we
could start using these curves for client certs, even if the baseline
requirements still prohibit them in TLS certs.



Jeremy


___
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: Other Curves

[Ryan Sleevi]

That seems altogether a bad idea for the ecosystem.

Current (and presently proposed) Mozilla policy does not allow them. Nor
are they supported in Mozilla NSS anymore (and their previous support was
not one you should use for security-critical purposes). Nor are they
supported in other UAs.

I'm sympathetic to the argument that "If they're not used for server certs,
what's the matter" - but I think there's a reasonable concern for anything
a CA signs/issues and avoiding ambiguity/risk, and that's something that
requires considerable amounts of energy.

On Wed, Feb 1, 2017 at 2:26 PM, Jeremy Rowley 
wrote:

> I know the use of other ECC curves comes up often, but I couldn't recall
> where Mozilla landed on using other ECC curves. Requests for secp256k1 and
> brainpool curves are increasing rapidly. If Mozilla updated its policy, we
> could start using these curves for client certs, even if the baseline
> requirements still prohibit them in TLS certs.
>
>
>
> Jeremy
>
>
> ___
> 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: Other Curves

[Richard Barnes]

Do you mean for signing by the CA, or as the key in the EE cert?

On Wed, Feb 1, 2017 at 2:26 PM, Jeremy Rowley 
wrote:

> I know the use of other ECC curves comes up often, but I couldn't recall
> where Mozilla landed on using other ECC curves. Requests for secp256k1 and
> brainpool curves are increasing rapidly. If Mozilla updated its policy, we
> could start using these curves for client certs, even if the baseline
> requirements still prohibit them in TLS certs.
>
>
>
> Jeremy
>
>
> ___
> 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

Other Curves

[Jeremy Rowley]

I know the use of other ECC curves comes up often, but I couldn't recall
where Mozilla landed on using other ECC curves. Requests for secp256k1 and
brainpool curves are increasing rapidly. If Mozilla updated its policy, we
could start using these curves for client certs, even if the baseline
requirements still prohibit them in TLS certs.

 

Jeremy



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: Suspicious test.com Cert Issued By GlobalSign

[Nick Lamb]

Thank you for undertaking this investigation Doug and for sharing what you 
found. I am glad to hear that GlobalSign had taken action to make similar 
issuances less likely in the future even before Andrew reported this.

In hindsight probably it would have been helpful to suggest to all members of 
Mozilla's root programme that they consider whether they needed one or more 
such "test domains" as the rules on DNS name validation have gradually 
tightened.

The existence of lists of "prevetted domains" for managed service accounts 
doubtless streamlines things considerably for valuable large corporate 
customers, but it does open up some additional vulnerability compared to a 
simpler model in which everything is vetted each time. I hope GlobalSign has 
policies in place to mitigate that vulnerability.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Suspicious test.com Cert Issued By GlobalSign

[Doug Beattie]

Hi Gerv,

We've researched the audit events around the certificate:

https://crt.sh/?sha256=9d503e7c6c4fb6e6d7436c07ff445b95214871ea13ac1cb3b0d7abbce9be6cfb

The domain test.com was inadvertently used in a certificate request and 
issuance - here are the audit events for the managed service account:

9/11/2015 11:41:20 - test.com added as a prevetted domains
9/11/2015 11:50 - Order received by CA
9/11/2015 11:51:02 - Certificate issued
9/11/2015 11:52:48 - Certificate revoked
9/11/2015 14:24:03 - test.com removed as a prevetted domain

Back in 2015, there were some GlobalSign testing in which users thought it was 
acceptable to use domains like test.com and example.com for testing purposes.  
Since this time, GlobalSign has implemented procedures to avoid any similar 
situations in the future.  We've purchased domains like globalsign-demo.com, 
globalsign-support.com and aeg-test.com for testing purposes

The issuance of certificates from production CAs always uses domains which have 
been properly verified in accordance with the BRs and our vetting policies and 
the use of "testing" domains is only permitted if the domains are properly 
vetted in accordance with our CPS.  Certainly, the reported misissuance over 
the past year have highlighted this to all CAs. 

As part of researching this reported misissuance, we've reviewed all orders and 
certificates we've issued since this time to test.com and example.com and found 
several orders in the pending or cancelled state, but none of them were ever 
issued.  We continue to stress the importance of proper testing within our 
development, QA and production environments to avoid future misissuances.

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Gervase
> Markham
> Sent: Thursday, January 26, 2017 4:20 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Suspicious test.com Cert Issued By GlobalSign
> 
> On 25/01/17 17:36, Andrew Ayer wrote:
> > I found another certificate for www.test.com that I believe was
> > mis-issued by GlobalSign:
> >
> >
> >
> https://crt.sh/?sha256=9d503e7c6c4fb6e6d7436c07ff445b95214871ea13ac1c
> b
> > 3b0d7abbce9be6cfb
> 
> Yes, that looks mis-issued. I realise this was some time ago now, but do the
> Globalsign reps on the list have any comment?
> 
> 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

Re: Useful Heuristics

[Hubert Kario]

On Tuesday, 31 January 2017 09:27:30 CET Peter Bowen wrote:
> On Tue, Jan 31, 2017 at 5:50 AM, Hubert Kario  wrote:
> > On Monday, 30 January 2017 23:48:51 CET Peter Bowen wrote:
> >> See notes inline about known cities with numbers in their name.
> >> 
> >> On Mon, Jan 30, 2017 at 10:39 AM, Peter Bowen  wrote:
> >> > While it is very hard to validate the subject content of certificates
> >> > outside of DNS names, there are a number of heuristics that may be
> >> > useful to trigger a deeper check to ensure that the data is accurate.
> >> > 
> >> > A couple of these that I've found useful are:
> >> > 
> >> > 1) If stateOrProvince or Locality type attributes contain a Number,
> >> > this is a red flag.  I've yet to find any verified legitimate case
> >> > where this is correct
> >> 
> >> Of course I hit send and then find a least one valid cases of a number:
> >> 
> >> In Egypt (EG) there is a city called "6th of October".
> >> 
> >> In the Czech Republic (CZ), ISO lists some subdivisions as having
> >> numbers (https://www.iso.org/obp/ui/#iso:code:3166:CZ).  Wikipedia
> >> seems to suggest that these might not be current
> >> (https://en.wikipedia.org/wiki/Regions_of_the_Czech_Republic), but I
> >> think it should be considered reasonable for a CA to rely upon ISO
> >> 3166.
> > 
> > No, they still exist:
> > https://en.wikipedia.org/wiki/Prague_1
> > http://www.praha1.cz/cps/index.html
> > (note the address at the bottom of the page)
> 
> Is the number part of the name of the stateOrProvince or is it a
> postalCode?  I know in Dublin there were numbered "postal districts"
> prior to the implementation of Eircode, but the city and county are
> both "Dublin" not "Dublin 8" or such.

it is used as the name of city, so the following:
Úřad městské části Praha 1 | Vodičkova 18, 115 68 Praha 1

is parsed as:

Company: Úřad městské části Praha 1
Street: Vodičkova
Building no: 18
Postal Code: 115 68
City: Praha 1
(implied) Country: Czech Republic
 
> > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> 
> Am I parsing this correctly as follows?
> 
> Company: Red Hat Czech s.r.o.
> Street Address: Purkyňova 99/71
> Postal Code: 612 45
> City: Brno
> Country: Czech Republic

yes

> Does this imply that addresses in the Czech Republic do not use a
> state or province?

yes, it's not used for postal addresses or legal documents, but if there's a 
field in form for it, it likely would be filled, so it being present in a X509 
cert would not be surprising...

that being said, for "Praha 1", the stateOrProvince would be "Praha" or 
"Hlavní město Praha"

Speaking of uncommon locality names, in Budapest the districts use Roman 
numerals for names: https://en.wikipedia.org/wiki/Budapest#Districts
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy