Re: Root Store Policy 2.5: Call For Review and Phase-In Periods

[Gervase Markham via dev-security-policy]

On 06/07/17 16:31, Doug Beattie wrote:
> Moving to a new CA within 6 months is certain reasonable, but having 
> enterprise customers also replace all certificates so the CA can be revoked 
> within 6 months might be a bit short, especially since several of those 
> months are over the holidays.  Would you consider an approach were the CAs 
> MUST not issue new certificates after 15 November (4 months) and the CAs 
> SHALL be revoked no later than 15 April (9 months)?

Yeah, OK. A bit late for this feedback :-), but I'll make a fix when I
get back. Can you file a bug, please?
https://github.com/mozilla/pkipolicy/issues

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

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 6, 2017 at 10:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> What EKU(s) get used with certs containing SRVName? I confess I don't
> understand this technology as well as I might.
>

Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth)
___
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]

On 06/07/17 16:20, Ryan Sleevi wrote:
> compelling to add support for, and the security boundary between 192-bits
> and 256-bits is somewhere in the "heat death of the universe" level
> security (see
> https://www.imperialviolet.org/2014/05/25/strengthmatching.html )

Perhaps this is the discussion we need to be having, because Arkadiusz
asserted the difference was "night and day". Arkadiusz: do you have
backing for your assertion that P-521 has meaningfully improved levels
of security over P-384?

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

Re: P-521

[J.C. Jones via dev-security-policy]

On Tue, Jun 27, 2017 at 1:49 PM, Tom .  wrote:

> On 27 June 2017 at 11:44, Alex Gaynor wrote:
> > I'll take the opposite side: let's disallow it before it's use expands
> :-)
>
> But is that what we're talking about? I didn't think the question was
> "Should we remove P-521 code from NSS" it's "Should we permit CAs to
> use P-521?"
>

Note: Forbidding P-521 by policy likely wouldn't prompt us to disable or
remove any code from NSS in any quick fashion; that curve is one of those
exported to WebCrypto, and we'd need to be sure we weren't breaking things
by pulling it from there.  Given the low usage of ECDH/ECDSA and the lack
of compatibility in Chrome, probably not, but we'd want to at least check.

-J.C.
___
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 Thu, Jul 6, 2017 at 10:57 AM, Gervase Markham  wrote:

> On 05/07/17 18:08, Ryan Sleevi wrote:
> > That is, the difference between, say:
> > "label": "Verisign/RSA Secure Server CA"
> > And
> > CKA_LABEL "Verisign/RSA Secure Server CA"
>
> Not much, but you've picked the clearest part of certdata.txt to compare
> :-)
>

Sure - because you haven't given much of a sense for what human readability
means. That is, whether or not \104\143 is more or less readable than 68:8F
(hex) or aI8= (base64) or NCHQ (base32), as an example.

The presumption here seems to be "format that I'm familiar with", but
that's a fairly subjective read. We already have machine-readability, and
we've established that tool-generation is strongly preferred (both for
correctness and consistency), so human-writability does not seem like it's
agreed upon goal. So where does human-readability factor in, and does it
make more sense to derive human-readability from the existing
machine-readability?


>
> > It isn't, because JSON can't.
>
> As Rob notes, you can basically have them in all but name.
>

I don't think that really holds, but I'm surprised to see no one pointing
it out yet.

For example, there is a meaningful difference between

# This is the CA with serial abcd
CKA_LABEL UTF8 "Verisign/RSA Secure Server CA"

# This is the hash 00:ab:cd:ef
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

If you wanted to express that in JSON, using Rob's bit, you'd end up with
{
  "label": "VeriSign/RSA Secure Server CA",
  "comment": "This is the CA with serial abcd"
},
{
  "sha1_hash": "\x00\xab\xcd\xed",
  "comment": "This is the hash 00:ab:cd:ef"
}

Except that wouldn't be a valid JSON string (or at least, not all
expressible byte sequences are, as they'd result in invalid unicode
sequences), so you'd have to do a further transformation, such as base64
decoding (or de-hexing), which means its once again less human-maintainable.

I suspect we're at the risk of ratholing here, but the lack of JSON
comments is a well-known limitation that continually negatively affects
those who pursue JSON schemas, so we should not be so quick to brush away
what is frequently a maintenance compliant.


> > 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.
>
> I don't think that follows. EV trustworthiness is a property of the root
> store. The root program makes those decisions, and it's entirely
> appropriate that they be encoded in root program releases. We also make
> decisions on "trust restrictions", so I'm not sure why you call that a
> "Firefox-specific need".
>

EV trustworthiness is an aspect of the application code - in this case, a
Web browser with UI surface being exposed. Do you believe EV makes sense
for, say, a utility like cURL or wget? Or for an application like PHP? Does
the EV issuance status of a CA affect something like Thunderbird?

Or consider other stores - like Chrome - in which EV-SSL status is granted
not solely by the presence of policy, but the associated Certificate
Transparency information. One cannot equivalently determine EV status
solely based on a policy status - it's more than that.


> > 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.
>
> Perhaps this is the disconnect. Several non-Firefox consumers have said
> they are very interested in an encoding of the root program's partial
> trust decisions.
>

Could you recall where this happened? It doesn't seem from this thread,
beyond Kai's remarks, but perhaps you're evaluating against the previous
threads?

No, because they could consume whatever copy of the upstream file
> Firefox had imported.
>
> I don't expect "Mozilla's root store's trust view" and "Trusted by
> Firefox" ever to diverge, apart from due to time skew, and perhaps
> occasionally due to unencodeable restrictions.
>

But they already do, regularly. Compare Firefox ESR with Firefox Beta with
Firefox stable, and then compare that with NSS releases (and different OS
distributions of those releases). There is already an inherent divergence.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Root Store Policy 2.5: Call For Review and Phase-In Periods

[Doug Beattie via dev-security-policy]

Gerv,

Moving to a new CA within 6 months is certain reasonable, but having enterprise 
customers also replace all certificates so the CA can be revoked within 6 
months might be a bit short, especially since several of those months are over 
the holidays.  Would you consider an approach were the CAs MUST not issue new 
certificates after 15 November (4 months) and the CAs SHALL be revoked no later 
than 15 April (9 months)?

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, June 22, 2017 8:50 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods
> 
> On 21/06/17 16:58, Doug Beattie wrote:
> >> It's worth noting that if we had discovered this situation for SSL -
> >> that an unconstrained intermediate or uncontrolled power of issuance
> >> had been given to a company with no audit - we would be requiring the
> >> intermediate be revoked today, and probably taking further action as well.
> >
> > Agree
> 
> After consultation, I have decided to implement this requirement with a
> phase-in period of six months, for already-existing intermediates. So before
> 15th January 2018 (add a bit because of Christmas) these customers, and any
> others like them at any other CA, need to have audits (over at least 30 days 
> of
> operations), move to a name-constrained intermediate, or move to a
> managed service which does domain ownership validation on each domain
> added to the system. I expect these two intermediates to be revoked on or
> before 15th January 2018.
> 
> I realise this is not what you were hoping for, but it's not reasonable to 
> leave
> unconstrained intermediates in the hands of those not qualified to hold them
> for a further 2 years. I am allowing six months because, despite the weakness
> of the previous controls, you were in compliance with them and so it's not
> reasonable to ask for a super-quick move.
> 
> https://github.com/mozilla/pkipolicy/commit/44ae763f24d6509bb2311d339
> 50108ec5ec87082
> 
> (ignore the erroneously-added logfile).
> 
> > Are there any other CAs or mail vendors that have tested name constrained
> issuing CAs? If using name constrained CAs don’t work with some or all of the
> mail applications, it seems like we might as well recommend a change to the
> requirement.
> 
> I am open to hearing further evidence on this point.
> 
> 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: FW: P-521

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 6, 2017 at 10:46 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 05/07/17 14:49, Alex Gaynor wrote:
> > Is it really true that additional curves are just additional parameters?
> I
>
> That was my assumption; additional clue on this point would be welcome.


As Alex mentioned - it's generally not the case. While you can implement
with generic parameters, this can create both security and performance
issues, and so the preference within cryptographic libraries is to maintain
optimized versions (optimized for constant time, which is not always easy,
but also optimized for performance).

For NSS, consider the contributions from Intel -
https://bugzilla.mozilla.org/show_bug.cgi?id=1073990 , the performance
analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1125028 , the
performance optimizations in
https://bugzilla.mozilla.org/show_bug.cgi?id=653236 , and the performance
issues in https://bugzilla.mozilla.org/show_bug.cgi?id=1293936 . In short,
it generally gravitates towards per-platform, per-curve optimizations.

I think it's also worthwhile to consider the performance impact -
https://www.imperialviolet.org/2010/12/21/eccspeed.html . Note where P-521
falls on that graph. While this is 7 years ago, the numbers have not (to my
knowledge) substantially improved in relation to eachother.

It's also useful to think of this similar to RSA. The Baseline Requirements
do not set a maximum bound on the RSA modulus size - merely specifying a
minimum of 2048. However, in practice, >= 8096 is not supported, due to
limitations that many platforms impose, due to the computational cost. So
the Web PKI does determine an effective limit, even if NSS supports up to
16K RSA moduli sizes (but imposes 16K as the limit, again, for performance
reasons).

So the Web PKI certainly imposes limits - for performance, security, and
interoperability - so it's not unreasonable to impose this same limit. The
performance gulf, and the added overhead, do not make it significantly
compelling to add support for, and the security boundary between 192-bits
and 256-bits is somewhere in the "heat death of the universe" level
security (see
https://www.imperialviolet.org/2014/05/25/strengthmatching.html )
___
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 05/07/17 18:08, Ryan Sleevi wrote:
> That is, the difference between, say:
> "label": "Verisign/RSA Secure Server CA"
> And
> CKA_LABEL "Verisign/RSA Secure Server CA"

Not much, but you've picked the clearest part of certdata.txt to compare :-)

> It isn't, because JSON can't.

As Rob notes, you can basically have them in all but name.

> 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.

I apologise that I seem not to have made this clear; my suggestion is
that the new file is canonical and (near-)complete, and certdata.txt,
ExtendedValidation.cpp and other files get generated from it, whenever
NSS/Firefox want to take a new release of the root store.

> 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.

I don't think that follows. EV trustworthiness is a property of the root
store. The root program makes those decisions, and it's entirely
appropriate that they be encoded in root program releases. We also make
decisions on "trust restrictions", so I'm not sure why you call that a
"Firefox-specific need".

> 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.

Perhaps this is the disconnect. Several non-Firefox consumers have said
they are very interested in an encoding of the root program's partial
trust decisions.

> doing - they're interested in what Firefox is doing, and to get that, they
> would need to consume certdata.txt as well.

No, because they could consume whatever copy of the upstream file
Firefox had imported.

I don't expect "Mozilla's root store's trust view" and "Trusted by
Firefox" ever to diverge, apart from due to time skew, and perhaps
occasionally due to unencodeable restrictions.

Anyway, off on holiday, back in 3 weeks :-)

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 06/07/17 14:44, Kai Engert wrote:
> My response was based on my interpretation of Gerv's suggestion, which I
> understood as follows:
> - certdata.txt remains the master, keeps maintained and published with NSS
> - we define a new file format that's accepted as the standard for several
>   root stores
> - we convert certdata.txt to that interchange format
> - we publish the conversion result (the Artifact)

My apologies. My suggestion is almost what you say, but with the
difference that the new format is the master (as it contains more info
than certdata.txt does) and certdata.txt gets regenerated whenever NSS
takes a new release of the root list, rather than the other way around.

So in this scenario the EV C++ file would be directly generated from the
new format; certdata.txt would not need to carry EV info. In fact, the
file format of certdata.txt would be unchanged.

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 05/07/17 15:10, Peter Bowen wrote:
> 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.

You are right; this is a bug. Server certs need to have constraints on
dNSName and ipAddress (v4 and v6), and email certs need to have
constraints on rfc822Name. It is not intended to require that e.g.
server certs have rfc822Name constraints in order to be considered
technically constrained.

What EKU(s) get used with certs containing SRVName? I confess I don't
understand this technology as well as I might.

Note that I'm going on holiday for 3 weeks; further engagement may have
to wait until I return.

Gerv
___
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]

On 05/07/17 14:49, Alex Gaynor wrote:
> Is it really true that additional curves are just additional parameters? I

That was my assumption; additional clue on this point would be welcome.

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?

[Kai Engert via dev-security-policy]

On Mon, 2017-07-03 at 20:47 -0400, Ryan Sleevi wrote:
> On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert  wrote:
> 
> > > > I suspect, means anyone could plug
> > > > in a modern CI
> > 
> > CI meaning Continuous Integration ?
> > 
> 
> Yes. Gerv's proposal rests on the idea of having a file committed that
> explains it in human-readable and machine-readable (simultaneously) form,
> and then have a continuous integration build translate that into something
> consumable by NSS, and then commit that generated file back into the tree
> (as I understand it). For example, the resulting certdata.txt or certdata.c

Ok. Should we go that path, then I'd prefer if the new file format lived in its
own repository, and that the conversion would be done as a manual step, and the
conversion results (certdata.txt for NSS, something else for Firefox EV data
etc.) get checked in to the NSS and Firefox repositories, together with version
information about the source. This would enable us to compare the converted
results and review them for correctness.

> Right. And JSON can't have comments. So we'd lose substantially in
> expressiveness.

I agree with Rob's comment that comments could be added as attributes, if
necessary. But ideally, everything that's necessary as a comment could just be
added a real attributes. The tool to add new entries could produce the various
human readable values that humans want to see, like the extracted subject/issuer
names, fingerprints.

It would be good if the tool offered a consistency check, to verify that all
derived attributes match the embedded certificates. (Or simpler, just regenerate
them.)


> "Artifact" = generated file run as part of a build process, and then
> checked back in.

Thanks for the explanation.


> > > Thought experiment: Why not have certdata.txt generate a CI artifact that
> > > interoperates for other consumers to use?
> > 
> > Are you suggesting that we should convert certdata.txt into a file format
> > that
> > others would prefer to consume?
> > 
> > Yes, that's another option.
> > 
> > But it wouldn't solve the idea to also store the Mozilla EV attributes in
> > the
> > common place. Firefox developers would have to start converting information
> > found inside NSS to Firefox application code.
> > 
> 
> I'm not sure I fully understand your response.

My response was based on my interpretation of Gerv's suggestion, which I
understood as follows:
- certdata.txt remains the master, keeps maintained and published with NSS
- we define a new file format that's accepted as the standard for several
  root stores
- we convert certdata.txt to that interchange format
- we publish the conversion result (the Artifact)

My comment meant, if certdata.txt is the master, and if certdata.txt is supposed
to be the master source for the complete set of CA trust/distrust information,
then it would also be the master place to store any EV attributes.

As a consequence, adding such EV attributes to the Firefox code, if required,
would require an additional conversion process, from certdata.txt, to the
subsets that the Firefox code needs to embed.


> The suggestion was that if
> there's some 'other format' that leads interoperability to downstream
> consumers, it 'could' be a path to take certdata.txt and have a tool that
> can generate that 'other format' from certdata.txt.

Understood. I was commenting on the consequence it would have for EV and Firefox
embedded code.


> The purpose of this thought experiment was to find what, if any,
> limitations exist in certdata.txt. You've highlighted a very apt and
> meaningful one, in theory - which is that EV data is a Mozilla Firefox (and
> exclusively Firefox) concept, while trust records are an aspect of the root
> store, hence, the dual expression between Mozilla Firefox source and NSS
> source. If we wanted to make "EV" a portion of NSS (which makes no sense
> for, say, Thunderbird), we could certainly express that - but it means
> carrying around unneeded and unused attributes for other NSS consumers.

Correct. If we defined certdata.txt as the master source for all data, we'd have
to carry all attributes that Firefox needs.

I don't see a problem with that, however, it would require full agreement from
the Firefox developers, that certdata.txt is indeed the master location, and
that the Firefox code must never fork this information, but only ever pick up
converted snapshots from certdata.txt. Not sure if this could be enforced.


> I don't disagree we can - on a technical level. But I don't agree that the
> ontology of invented partial distrust holds, nor is it terribly useful to
> try to expect us to generalize distrust for the various ways in which CAs
> fail the community.

Well, the invented partial distrust mechanisms are the status quo, and it seems
this group hasn't been able to identify better practical solutions yet.

Why not document the status quo in a structured way, if it allows other
consumers to benefit? Maybe