Re: Policy 2.4 Proposal: Update required version number of Baseline Requirements to 1.3.7

2017-01-18 Thread Ryan Sleevi 
On Wed, Jan 18, 2017 at 7:16 AM, Gervase Markham  wrote:

> On 17/01/17 23:32, Ryan Sleevi wrote:
> > BRs 1.3.0 ( https://cabforum.org/wp-content/uploads/CAB-Forum-BR-
> 1.3.0.pdf
> > ) already include the clause (in Section 2.2) that:
> > "The CA SHALL publicly give effect to these Requirements and represent
> > that it will adhere to the latest published version."
>
> Hmm. I was not aware of that. I wonder how many CAs are aware that
> according to the BRs, any changes to the BRs by default come in
> immediately the motion is passed and the document is updated. Perhaps
> I'm the only person who didn't know this.
>

I am surprised, since we discussed it during the Scottsdale F2F in the
CA/Browser Forum :)

See
https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#Compliance-Assessment-Coordination-with-auditors-and-browsers

"Some CAs say they were audited to an older version of the BRs; therefore
it would appear that the CA only thinks the need to comply with the older
version of the BRs. This is not correct as the BRs state that the CA has to
have a CPS statement that they comply with the latest version of the BRs."


> You'll need to give me a more specific reference; I don't remember any
> such question, and a quick scan back through top-level posts from Apple
> employees hasn't revealed it.
>

There's not some single top-level post that states this - but it was the
whole purpose of Ballots 180/181, which is the view that the Forum did not
follow its Bylaws (with respect to either voting vs IP review period or
with respect to the formation of a PAG following disclosures, going back to
the first adoption of the BRs) therefore invalidates the adoption. Which is
why we had Ballots 180/181 - to ensure that all members were happy that
'the process' was followed and all documents produced were done so in a way
consistent with the Bylaws.

It's procedural administrivia, certainly, and not one anyone advanced until
Apple raised concerns, largely in part do to the proposed ways of resolving
the lack of disclosure notices being provided during much of Dean's
chairing.


> So the suggestion is that we just update our policy to require adherence
> to the latest version of the BRs, on the basis that this is what the BRs
> require anyway?


Yes.

That gets you to Ballot 181 / v 1.4.2. However, you would then need to
clarify (at least for 1.4.2) that the only acceptable forms of any other
are the 169 methods.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

2017-01-18 Thread Jakob Bohm 

On 18/01/2017 16:20, Gervase Markham wrote:

On 17/01/17 23:27, Jakob Bohm wrote:

Notes on the text in that branched section (other than the actual
change discussed here):


This paranthesis indicates none of these are in scope for this
particular issue, just something that might be their own issues,
either already pending or interesting to queue up later.



- It does not include some other changes under discussion (such as the
 new version of the BRs).  This may need to be manually reapplied after
 merging in the movement of text from the inclusion to the audit
 section.


The magic of git :-)



OK, didn't know git could handle the lines moved and changed case
(other than by possibly punting to the user due to removed lines not
matching).


- There is no clause that can formally cover the recent decision by
 Mozilla to disqualify a specific auditor in Hong Kong.  E.g. something
 along the lines that Mozilla may publicly announce at /url/ that
 certain parties that match these criteria will not be trusted for
 reasons there stated.


Inclusion policy bullet 16, together with bullets 13 and 14, together
make it clear that the decision about whether to accept audits from a
particular auditor rests with Mozilla.


I found the language in the moved/new audit section to suggest that CAs
really wouldn't have a reason to ask Mozilla before choosing a major
name brand WebTrust auditor such as the one in question.  Also, there
is the question if any existing CAs (other than the misaudited one)
already use that same distrusted auditor.




- There is no set of non-ETSI audit criteria for e-mail certificates as
 trusted by Mozilla Thunderbird.


Do you have some to propose?



No, but I seem to recall someone else made a closely related suggestion
in an earlier thread (not sure which one).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

2017-01-18 Thread Kurt Roeckx 
On Wed, Jan 18, 2017 at 07:23:35AM -0800, Peter Bowen wrote:
> 
> > On Jan 18, 2017, at 7:18 AM, Gervase Markham  wrote:
> > 
> > On 17/01/17 23:33, Jakob Bohm wrote:
> >> How about "_and versions and strong (>= 256 bits) hashes_",
> > 
> > Do people think we need to go this far?
> > 
> > If we do, we'll need them to specify filenames, not just document
> > titles. Otherwise, one wouldn't know if the hash was a .doc, a .pdf, or
> > what.
> 
> I don’t think hashes of documents is necessary, but I do think including the 
> version information is critical.
> 
> I would support requiring inclusion of the full distinguished names of all 
> the CAs that are covered (and maybe their SPKI hash), as that is currently an 
> even larger gap.

And I would like to see that as a requirement in the audit report,
which CA are actually checked.


Kurt

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

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

2017-01-18 Thread Peter Bowen 

> On Jan 18, 2017, at 7:18 AM, Gervase Markham  wrote:
> 
> On 17/01/17 23:33, Jakob Bohm wrote:
>> How about "_and versions and strong (>= 256 bits) hashes_",
> 
> Do people think we need to go this far?
> 
> If we do, we'll need them to specify filenames, not just document
> titles. Otherwise, one wouldn't know if the hash was a .doc, a .pdf, or
> what.

I don’t think hashes of documents is necessary, but I do think including the 
version information is critical.

I would support requiring inclusion of the full distinguished names of all the 
CAs that are covered (and maybe their SPKI hash), as that is currently an even 
larger gap.

Thanks,
Peter


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

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

2017-01-18 Thread Gervase Markham 
On 17/01/17 23:27, Jakob Bohm wrote:
> Notes on the text in that branched section (other than the actual
> change discussed here):
> 
> - It does not include some other changes under discussion (such as the
>  new version of the BRs).  This may need to be manually reapplied after
>  merging in the movement of text from the inclusion to the audit
>  section.

The magic of git :-)

> - There is no clause that can formally cover the recent decision by
>  Mozilla to disqualify a specific auditor in Hong Kong.  E.g. something
>  along the lines that Mozilla may publicly announce at /url/ that
>  certain parties that match these criteria will not be trusted for
>  reasons there stated.

Inclusion policy bullet 16, together with bullets 13 and 14, together
make it clear that the decision about whether to accept audits from a
particular auditor rests with Mozilla.

> - There is no set of non-ETSI audit criteria for e-mail certificates as
>  trusted by Mozilla Thunderbird.

Do you have some to propose? Although I'm not sure it's in scope for
this particular issue.

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

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

2017-01-18 Thread Gervase Markham 
On 17/01/17 23:33, Jakob Bohm wrote:
> How about "_and versions and strong (>= 256 bits) hashes_",

Do people think we need to go this far?

If we do, we'll need them to specify filenames, not just document
titles. Otherwise, one wouldn't know if the hash was a .doc, a .pdf, or
what.

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

Re: Policy 2.4 Proposal: Update required version number of Baseline Requirements to 1.3.7

2017-01-18 Thread Gervase Markham 
On 17/01/17 23:32, Ryan Sleevi wrote:
> BRs 1.3.0 ( https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf
> ) already include the clause (in Section 2.2) that:
> "The CA SHALL publicly give effect to these Requirements and represent
> that it will adhere to the latest published version."

Hmm. I was not aware of that. I wonder how many CAs are aware that
according to the BRs, any changes to the BRs by default come in
immediately the motion is passed and the document is updated. Perhaps
I'm the only person who didn't know this.

> So despite Mozilla Policy requiring 1.3.0, up until the passage of
> Ballots 180/181, CAs were already on the hook and expected to comply
> with the BRs 1.4.1 - meaning implementing the methods of Ballot 169 by
> 1 March 2017.
> 
> Up until the questions by Apple in the Forum, there had not been any
> debate or disagreement about what the 'latest published version' was,
> either within the Forum or within mozilla.dev.security.policy. 

You'll need to give me a more specific reference; I don't remember any
such question, and a quick scan back through top-level posts from Apple
employees hasn't revealed it.

> It's
> unclear whether Mozilla shares Apple's interpretation about the
> legitimacy of all versions of the BRs prior to 1.4.2, but based on
> your replies, it does not seem you agree on substance. That is, BRs
> 1.3.0 were/are a valid version of the BRs, at least within the spirit
> and intent of the Mozilla policy, and so too by that logic are
> versions 1.3.7, 1.4.1, and 1.4.2, which were passed in the same
> manner.

Yes, that's my view.

> and it
> seems that the reference to a specific version in Policy 2.4 is
> perhaps superflous, so long as the Section 2.2 remains in force in the
> BRs.

So the suggestion is that we just update our policy to require adherence
to the latest version of the BRs, on the basis that this is what the BRs
require anyway?

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