Re: Machine- and human-readable format for root store information?

[Rob Stradling via dev-security-policy]

On 05/07/17 18:08, Ryan Sleevi wrote:

On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham wrote:



That is, the difference between, say:
"label": "Verisign/RSA Secure Server CA"
And
CKA_LABEL "Verisign/RSA Secure Server CA"

I would argue there isn't a meaningful difference for "human readability",
and it's more a subjective preference. Before we fixate on those, I'm
hoping we should get objective use cases nailed down. That's why I'm trying
to understand how you're evaluating that spectrum. Is it because it's
something you'd like to maintain, because you think it should be "readable"
on a webpage, etc?


How it is sans-comments is irrelevant, because it has comments. :-)


It isn't, because JSON can't.


Unless...

{"label":"Verisign/RSA Secure Server CA","comments":"These are some 
comments"}


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Machine- and human-readable format for root store information?

[Ryan Sleevi via dev-security-policy]

On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 29/06/17 16:27, Ryan Sleevi wrote:
> > Well, the current certdata.txt is a text file. Do you believe it's
> human-readable, especially sans-comments?
>
> Human readability is, of course, a little bit of a continuum. You can
> open it in a text editor and get some sense of what's going on, but it's
> far from ideal.


Unfortunately, your answers don't really help capture your goals - and thus
make this a very difficult endeavor to satisfy.

You haven't really established on what principles you believe JSON (which
seems to be your preferred format, and which does not support comments) is
more favorable than the current format.

That is, the difference between, say:
"label": "Verisign/RSA Secure Server CA"
And
CKA_LABEL "Verisign/RSA Secure Server CA"

I would argue there isn't a meaningful difference for "human readability",
and it's more a subjective preference. Before we fixate on those, I'm
hoping we should get objective use cases nailed down. That's why I'm trying
to understand how you're evaluating that spectrum. Is it because it's
something you'd like to maintain, because you think it should be "readable"
on a webpage, etc?


> How it is sans-comments is irrelevant, because it has comments. :-)


It isn't, because JSON can't.


> Of course, those changing the root store might need access to the
> compilation tool. But from a Mozilla PoV, that's just Kai normally. And
> if people were used to editing and consuming certdata.txt, they could
> continue to do it that way.


I'm thinking you may have misunderstood? Are you suggesting certdata.txt is
canonical or not? Otherwise, they can't continue doing it hat way - they
would have to use whatever format you adopt, and whatever new tools.

>
> Thought experiment for you: if we decided to make the root store its own
> thing with its own repo and its own release schedule, and therefore NSS
> became a downstream consumer of it, where on occasion someone would
> "take a release" by generating and checking in certdata.txt from
> whatever format we decided to use, what problems would that cause?


Would you see it being as independent, or subservient to Firefox? If you
saw it as independent, then you would presumably need to ensure that - like
today - Firefox-specific needs, like EV or trust restrictions, did not
creep into the general code.

Of course, it seems like your argument is you want to express the Firefox
behaviors either directly in NSS (as some trust restrictions are, via code)
or via some external, shared metafile, which wouldn't be relevant to
non-Firefox consumers.

More broadly, that proposal simply adds more work and moving parts, and
arguably undermines your stated goals - because downstream parties like
those identified are not interested in what the "upstream root store" is
doing - they're interested in what Firefox is doing, and to get that, they
would need to consume certdata.txt as well.

I'm fairly certain we're not on the same page as to what problems consumers
are facing in this space, and this may be contributing to the
misunderstanding. If you look at major parties doing stuff in this space -
Cloudflare's CFSSL, SSLLabs, Censys - the goal is generally "trusted by
Firefox," as the goal is debugging and helping users properly configure.
crt.sh is more interested in "trusted by NSS," due to the policy
enforcement.

That is - there are two separate problems - trusted by browser X, and
trusted by root program Y. We should at least recognize these as related,
but separable problems. The need to identify the former is why, for
example, folks scrape the historic releases (or maintain copies, such as of
the Microsoft CTLs).

>
> > So clearly, we get in situations where not all restrictions are
> expressible.
>
> Sure. As I said, I'm not interested in an arbitrarily complex file
> format, so it will always be possible to come up with restrictions we
> can't encode.


I'm still not sure I understand what you believe is arbitrarily complex.
All restrictions can be encoded - it's a question of whether the complexity
is useful. For example, you could encode a BPF like state machine for
restrictions - which can be fully encoded and processed, but which would
add code. But one could easily make the argument that a BPF like filter
library is useful and worthwhile for any number of Root stores.

It's very easy to get lost in this games, and so perhaps it may be useful
if you could contemplate what your core goals are, for Mozilla. I'm not
sure it would be fair to express hypothetical's for Apple or others, in
their absence, but I hope you can appreciate why this feels like a lot of
"ambiguous make work," as specified.

But whatever format Apple chooses, unless they go the
> "arbitrary complexity" path, they will have that problem, no?


Are you familiar with how Apple currently expresses their root store and
how applications 

Re: SRVNames in name constraints

[Peter Bowen via dev-security-policy]

> On Jul 5, 2017, at 4:23 AM, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 03/07/17 17:44, Peter Bowen wrote:
>> We still need to get the policy changed, even with the ballot.  As
>> written right now, all name constrained certificates are no longer
>> considered constrained.
> 
> I'm not sure what you mean... What's the issue you are raising here?

Right now (Policy v2.5) says:

Intermediate certificates which have at least one valid, unrevoked chain up to 
such a CA certificate and which are not technically constrained to prevent 
issuance of working server or email certificates. Such technical constraints 
could consist of either:

an Extended Key Usage (EKU) extension which does not contain any of these 
KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or:
name constraints which do not allow Subject Alternative Names (SANs) of any of 
the following types: dNSName, iPAddress, SRVName, rfc822Name
The second bullet says “any”.  As the rule for name constraints is that if they 
are not present for a type, then any name is allowed, you have to include name 
constraints for all four types.  The issue comes down to the definition of 
“working server” certificates.  Mozilla does not use either rfc822names or 
SRVName for name validation for server authentication, but you could have a 
valid server certificate that has only these names.  Is NSS/Firefox code 
considered a “technical constraint”?  If not, then all technically constrained 
CA certificates need to have constraints on SRVName and rfc822Name type General 
Names in addition to what they have now.

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

Re: FW: P-521

[Alex Gaynor via dev-security-policy]

On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I agree crypto algorithms are not "gotta catch 'em all", but the
> algorithm is ECDH, which NSS must implement anyway to support P-256 and
> P-384, and a curve is just another set of parameters to it. I also think
> that there is little value and there is potential confusion (as we have
> seen) in Mozilla mandating a more restrictive set than the BRs and than
> Microsoft:
>

Is it really true that additional curves are just additional parameters? I
haven't gone source-diving in NSS recently, but my understanding is that
most crypto libraries provide optimized assembly routines for scalar
multiplication on a per-curve basis -- OpenSSL appears to have over 10,000
lines of assembly-generating-perl for P256 alone (
https://github.com/openssl/openssl/tree/master/crypto/ec/asm).

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

Re: FW: P-521

[Gervase Markham via dev-security-policy]

I agree crypto algorithms are not "gotta catch 'em all", but the
algorithm is ECDH, which NSS must implement anyway to support P-256 and
P-384, and a curve is just another set of parameters to it. I also think
that there is little value and there is potential confusion (as we have
seen) in Mozilla mandating a more restrictive set than the BRs and than
Microsoft:

> NIST FIPS PUB 186-4 recommends 4 curves over Prime Fields for use in US 
> public administration. These are:
> P-192, P-256, P-384, P-521
> 
> Baseline Requirements require:
> P-256,P-384 or  P-521
> 
> Key Requirements for Microsoft Trusted Root Program:
> P-256, P-384, P-521
> 
> Mozilla Root Store Policy:
> P-256, P-384

If there are, or become, interoperability issues in practice, then I
think we can leave that as the CA's lookout.

So I am currently minded to restore P-521 to the Mozilla permitted list.

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

Re: Machine- and human-readable format for root store information?

[Gervase Markham via dev-security-policy]

On 03/07/17 16:09, Kai Engert wrote:
> I'd prefer a simple open source tool that operates on files, which can be used
> from a command line, with a free license, e.g. MPL2.

Of course.

> If the intention is to define a file format that is shared with other groups,
> who would be the owner of the file format? 

Good question.

> What if another group needs to
> introduce additional fields into the file format, that aren't of interest to
> Mozilla or NSS?

Using something like JSON means that people can add arbitrary keys for
their own use that everyone else can ignore. We'd need a lightweight
mechanism for how to do that, but it's not an uncommon pattern.

>> We could do this with any approach. Are you interested in the idea of
>> making the trust list an independently-maintained item, which is just
>> pulled into NSS each time an NSS release is done?
> 
> Yes, I had previously suggested this here:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1294150

I think that having a new file format which encoded more or all of the
restrictions on CAs would mitigate some of the issues raised in that bug.

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

Re: Machine- and human-readable format for root store information?

[Gervase Markham via dev-security-policy]

On 03/07/17 16:53, Kai Engert wrote:
> On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote:
>> On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote:
>>> Well, the fact that we now use Git,
> 
> NSS and the root store don't use Git, it uses HG/Mercurial.

Yes, apologies. I guess I meant $MODERN_VCS.

>>> I suspect, means anyone could plug
>>> in a modern CI
> 
> CI meaning Continuous Integration ?

Yes.

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

Re: Machine- and human-readable format for root store information?

[Gervase Markham via dev-security-policy]

On 29/06/17 16:27, Ryan Sleevi wrote:
> Well, the current certdata.txt is a text file. Do you believe it's 
> human-readable, especially sans-comments?

Human readability is, of course, a little bit of a continuum. You can
open it in a text editor and get some sense of what's going on, but it's
far from ideal.

How it is sans-comments is irrelevant, because it has comments. :-)

(For those not familiar, here's a sample from certdata.txt:

# Trust for Certificate "Verisign/RSA Secure Server CA"
CKA_CLASS CK_OBJECT_CLASS CKO_NETSCAPE_TRUST
CKA_TOKEN CK_BBOOL CK_TRUE
CKA_PRIVATE CK_BBOOL CK_FALSE
CKA_MODIFIABLE CK_BBOOL CK_FALSE
CKA_LABEL UTF8 "Verisign/RSA Secure Server CA"
CKA_CERT_SHA1_HASH MULTILINE_OCTAL
\104\143\305\061\327\314\301\000\147\224\141\053\266\126\323\277
\202\127\204\157
END
CKA_CERT_MD5_HASH MULTILINE_OCTAL
\164\173\202\003\103\360\000\236\153\263\354\107\277\205\245\223
END


> Please realize that this makes it impossible to effectively test changes, 
> without running said tool. This is, again, why certdata.txt being generated 
> is part of the build - so that when you change a file, it's reflected in the 
> build and code and you can effectively test.

Of course, those changing the root store might need access to the
compilation tool. But from a Mozilla PoV, that's just Kai normally. And
if people were used to editing and consuming certdata.txt, they could
continue to do it that way.

Thought experiment for you: if we decided to make the root store its own
thing with its own repo and its own release schedule, and therefore NSS
became a downstream consumer of it, where on occasion someone would
"take a release" by generating and checking in certdata.txt from
whatever format we decided to use, what problems would that cause?

> That's why "machine-readable" is, in effect, a must-have.

I'm not sure anyone is arguing with that.

> So clearly, we get in situations where not all restrictions are expressible.

Sure. As I said, I'm not interested in an arbitrarily complex file
format, so it will always be possible to come up with restrictions we
can't encode. But whatever format Apple chooses, unless they go the
"arbitrary complexity" path, they will have that problem, no?

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

Re: SRVNames in name constraints

[Gervase Markham via dev-security-policy]

On 03/07/17 17:44, Peter Bowen wrote:
> We still need to get the policy changed, even with the ballot.  As
> written right now, all name constrained certificates are no longer
> considered constrained.

I'm not sure what you mean... What's the issue you are raising here?

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

Re: SRVNames in name constraints

[Gervase Markham via dev-security-policy]

On 03/07/17 17:29, Peter Bowen wrote:
> "name constraints which do not allow Subject Alternative Names (SANs)
> of any of the following types: dNSName, iPAddress, SRVName,
> rfc822Name"
> 
> SRVName is not yet allowed by the CA/Browser Forum Baseline
> Requirements (BRs), so I highly doubt any CA has issued a
> cross-certificate containing constraints on SRVName-type names.  Until
> the Forum allows such issuance, I think this requirement should be
> changed to remove SRVName from the list.  If the Forum does allow such
> in the future, adding this back can be revisited at such time.

Clearly, the set of things CAs must abide by is the restrictive union of
the BRs and all the browser policies. So this is in the nature of an
"unusable permission". So I don't think it's doing any harm.

Are there any plans for a ballot to enable this? I thought that perhaps
there might be. If so, it seems easiest to just leave it.

Gerv

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

FW: P-521

[Arkadiusz Ławniczak via dev-security-policy]

Hi

As CERTUM, we are not aware of any implementations which do not support P-521 
(with the exception of BoringSSL where P-512 is disabled but not unsupported). 
All popular web browsers support all three P-256, P-384 and P521 curves. The 
P-521 certificates are imported correctly even to the old iPhone 5S (iOS 
10.3.2) or to the Samsung SM-T325 (Android 4.4.2).  If the software does not 
support elliptic curves, it does not support them all - all or none.

Also, when we consider  NIST Special Publication 800-57 Part 1, Revision 4. 
Recommendation for Key Management, P. 53, Table 2: Comparable strengths 
(http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf)
we can see the strengths of algorithms given as security bits. It clearly shows 
that algorithms based on P512 + curves represent 256 bits of security while 
curve 384 represents 192 bits.
>From a cryptosystem security point of view - especially rootCA and ARL - P384 
>to P521 is like "day to night". This is particularly important for 
>crypto-systems to be safe for decades.


PS.
Some example from Adobe world. The new AATL Technical Requirements (June 2017) 
states that:

>RCA8 [...]For Elliptic Curve signature technology, a key length of 256-bit or 
>higher is required for RCA certificates.
>A key length of 384-bit or higher is required for RCA certificates that are 
>issued on or after 1 July 2017. [...]

The key is: "or higher". The thing is the vendors'/browsers' policies should be 
consistent with the functioning of the market and therefore we belive that 
removing P-521 from Mozilla Policy was not a good thing.


--
Arkadiusz Ławniczak

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+arkadiusz.lawniczak=assecods...@lists.mozilla.org]
 On Behalf Of Arkadiusz Ławniczak via dev-security-policy
Sent: Thursday, June 29, 2017 9:12 AM
To: r...@sleevi.com; Alex Gaynor
Cc: MozPol; Gervase Markham; Kurt Roeckx
Subject: RE: P-521

Hello all

As CERTUM, we would like to create and submit to Mozilla our two new root CAs. 
There would be nothing unusual about this but I've found that Mozilla Policy 
doesn't allow to use algorithm P-521 and that is what we want to use in our 
root CA.

NIST FIPS PUB 186-4 recommends 4 curves over Prime Fields for use in US public 
administration. These are:
P-192, P-256, P-384, P-521

Baseline Requirements require:
P-256,  P-384 or  P-521

Key Requirements for Microsoft Trusted Root Program:
P-256, P-384, P-521

Mozilla Root Store Policy:
P-256, P-384

P-256, P-384 and P-521 curves are commonly implemented in all popular 
cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or 
Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware 
cryptographic modules.

But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has 
limited its policy to only two curves P-256 and P-384. 
The reasons for this decision are known only to this agency and Mozilla. It can 
be assumed that stronger cryptography is currently embarrassing for the NSA, 
and the safety margin over the operation time is low. 
>From the point of view of Certum CA, the two alleged reasons are irrelevant.

This is true that, according to NSA "Suite B" recommendations, standards have 
been developed such as:

1) IETF RFC 6460, for TLS
2) IETF RFC 6379, for IPsec
3) IETF RFC 6318, for SMIME
4) IETF RFC 5759, for X.509 certificate and CRL

However, we must recognize that X.509 end entities and service certificates are 
issued for one year, up to three years. CA root certificates are issued for 25 
years. They must rely on stronger cryptography as well as the ARLs they publish.

Not every commercial organization must also apply to NSA recommendations and 
its depleted cryptographic algorithms. Especially if it operates in Europe and 
cares for the safety of its customers.

--
Arkadiusz Ławniczak
Analyst
Security and Trust Services Division
Asseco Data Systems S.A.
Biuro w Szczecinie
ul. Królowej Korony Polskiej 21
70-486 Szczecin
mob. +48 669992104
arkadiusz.lawnic...@assecods.pl
assecods.pl

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+arkadiusz.lawniczak=assecods...@lists.mozilla.org]
 On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, June 28, 2017 3:42 PM
To: Alex Gaynor
Cc: Gervase Markham; MozPol; Kurt Roeckx
Subject: Re: P-521

On Tue, Jun 27, 2017 at 2:44 PM, Alex Gaynor via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> I'll take the opposite side: let's disallow it before it's use expands
> :-)
> P-521 isn't great, and there's really no value in proliferation of 
> crypto algorithms, as someone told me: "Ciphersuites aren't pokemon, 
> you shouldn't try to catch 'em all". There's no real use cases P-521 
> enables, and not supporting it means one less piece of code to drag 
> around as we move towards better curves/signature algorithms like Ed25519 and 
> co.


+1 to 

Re: ETSI auditors still not performing full annual audits?

[cornelia.enke66--- via dev-security-policy]

Am Montag, 19. Juni 2017 21:15:09 UTC+2 schrieb Kathleen Wilson:
> I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an 
> audit statement that I received for SwissSign. I have copied the bug 
> description below, because I am concerned that there still may be ETSI 
> auditors (and CAs?) who do not understand the audit requirements, see below.
> 
> ~~~
> SwissSign provided their annual audit statement:
> https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299
> 
> Problems noted in it:
> -- "Agreed-upon procedures engagement" - special words for audits - does not 
> necessarily encompass the full scope
> -- "surveillance certification audits" - does not necessarily mean a full 
> audit (which the BRs require annually)
> -- "point in time audit" -- this means that the auditor's evaluation only 
> covered that point in time (note a period in time)
> -- "only intended for the client" -- Doesn't meet Mozilla's requirement for 
> public-facing audit statement.
> -- "We were not engaged to and did not conduct an examination, the objective 
> of which would be the expression of an opinion on the Application for 
> Extended Validation (EV) Certificate. Accordingly, we do not express such an 
> opinion. Had we performed additional procedures, other matters might have 
> come to our attention that would have been reported to you." -- some of the 
> included root certs are enabled for EV treatment, so need an EV audit as well.
> 
> 
> According to section 8.1 of the CA/Browser Forum's Baseline Requirements: 
> "Certificates that are capable of being used to issue new certificates MUST 
> ... be ... fully audited in line with all remaining requirements from this 
> section. 
> ...
> The period during which the CA issues Certificates SHALL be divided into an 
> unbroken sequence of audit periods. An audit period MUST NOT exceed one year 
> in duration."
> 
> So, a full period-in-time audit is required every year.
> 
> After I voiced concern 
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1142323#c27) the CA provided an 
> updated audit statement to address the concerns I had raised in the bug:
> https://bugzilla.mozilla.org/attachment.cgi?id=8867948
> I do not understand how the audit statement can magically change from 
> point-in-time to a period-in-time.
> ~~~
> 
> I will greatly appreciate thoughtful and constructive input into this 
> discussion about what to do about this SwissSign audit situation, and if this 
> is an indicator that ETSI auditors are still not performing full annual 
> audits that satisfy the CA/Browser Forum's Baseline Requirements.
> 
> Thanks,
> Kathleen

Hello togehter

the Report is the annual Attestation letter. I agree htat the Format was not 
the best, I also agree that it would be worth to have a confirmed Audit 
Statement what is understandable and readable by the relevant responsible 
persons. 

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