Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

2021-02-18 Thread Ben Wilson via dev-security-policy 
All,

I have edited the proposed resolution of Issue #192

as follows:

Subsection 3 of MRSP Section 3.1.4. would read:

"The publicly-available documentation relating to each audit MUST contain
at
least the following clearly-labelled information: ...

3. name of the lead auditor and qualifications of the team performing the
audit, as required by section 3.2;
..."

Section 3.2 would read:

"A Qualified Auditor MUST have relevant IT Security experience, or have
audited a number of CAs, and be independent and not conflicted. People have
competence, partnerships and corporations do not. Each Audit Report MUST be
accompanied by documentation provided to Mozilla of the audit team
qualifications

sufficient for Mozilla to determine the competence, experience, and
independence of the Qualified Auditor."

The wiki page linked above will provide further details on how to submit
documentation of the audit team's qualifications (which may be separate
from the audit letter itself).

Ben





On Mon, Feb 15, 2021 at 6:01 PM Watson Ladd via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Monday, February 15, 2021 at 3:07:12 PM UTC-8, Jeff Ward wrote:
> > On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote:
> > > Apologies for belaboring the point, but I think we might be talking
> past
> > > eachother.
> > >
> > > You originally stated “The only place I am aware that lists the audit
> > > partner in a comparable world is the signing audit partner on public
> > > company audits in the US, which is available on the SEC website.” I
> gave
> > > two separate examples of such, and you responded to one (FPKI) by
> saying
> > > the report was not public (even when it is made available publicly),
> and
> > > the other I didn’t see a response to.
> > >
> > > This might feel like nit-picking, but I think this is a rather serious
> > > point to work through, because I don’t think you’re fully
> communicating
> > > what you judge to be a “comparable world”, as it appears you are
> dismissing
> > > these examples.
> > >
> > > I can think of several possible dimensions you might be thinking are
> > > relevant, but rather than assume, I’m hoping you can expand with a few
> > > simple questions. Some admittedly seem basic, but I don’t want to take
> > > anything for granted here.
> > >
> > > 1) Are you/the WTTF familiar with these audit schemes?
> > >
> > > 2) Are you aware of schemes that require disclosing the relevant
> skills and
> > > experience of the audit team to the client? (E.g. as done by BSI C5
> audits
> > > under ISAE 3000)
> > >
> > > 3) Are you aware of such reports naming multiple parties for the use
> of the
> > > report (e.g. as done by FPKI audits)
> > >
> > > 4) Are you aware of schemes in which a supplier requires a vendor to
> be
> > > audited, and ensures that the customer of supplier are able to access
> such
> > > audits as part of their reliance upon supplier? (Note, this doesn’t
> have to
> > > be limited to ISMS systems)
> > >
> > > I’m trying to understand what, given the prevalence of these
> practices,
> > > makes these instances *not* a comparable world, since it seems that
> helps
> > > move closer to solutions.
> > Ryan, I hope you are not suggesting I am dodging you points. That would
> be absurd. Let me use different words as comparable world seems to be
> tripping you up. You are not providing a general/public distribution
> example to make your point so it is baseless. You are using a restricted
> opinion from EY and neither Ryan Sleevi nor Google are listed as the two
> intended users. The closest I have seen to support your desire to name
> individual auditors is in public company audit reports, which are housed on
> the SEC website. To be clear, of your two examples, one is an opinion,
> which is restricted, and the other represents the guidelines. Perhaps you
> have seen a public/general distribution report from your second opinion as
> I do not see it in this thread. I am aware, as mentioned previously, of the
> Federal PKI program desiring to know more about team members, but that is
> not listed in a non-restricted report, in a public/general distribution
> format.
>
> I can click on the URL and read it.  This seems to be the very definition
> of public, even if the audit report says it is not for reliance upon by the
> general public. I fully appreciate that this may be a technicality in the
> world of auditing, but it is very confusing to those of us who are less
> familiar.
>
> > Jeff
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Re: Questions About DigiCert .onion Certificate SubjectPublicKey Hash

2021-02-18 Thread Ryan Sleevi via dev-security-policy 
This is already tracked as https://github.com/cabforum/servercert/issues/190
and is waiting the completion of SC41v2 in the CA/Browser Forum Server
Certificate Working Group before working on (along with a cluster of
related .onion fixes)

On Thu, Feb 18, 2021 at 12:05 PM SXIA via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello,
>
> As required by CABForum guidelines, CAs must include the hash of an ASN.1
> SubjectPublicKey of the .onion service. For example,
> https://crt.sh/?id=3526088262 shows the SHA256 of the public key of
> archivev3qli37bju4rlh27glh24lljyezwxf4pokmrdbpefjlcrp5id.onion is
> 08afa9604f4cd74a1a867f3ffcf61faacdb19785a9d4c378f72a54503f73dd65
>
> Since this a v3 address, it is not difficult to extract the public key
> from .onion domain. Below is the hexdump of hs_ed25519_public_key
>
> 3d 3d 20 65 64 32 35 35  31 39 76 31 2d 70 75 62
> 6c 69 63 3a 20 74 79 70  65 30 20 3d 3d 00 00 00
> 04 44 74 54 95 dc 16 8d  fc 29 a7 22 b3 eb e6 59
> f5 c5 ad 38 26 6d 72 f1  ee 53 22 30 bc 85 4a c5
>
> So the public key (32 bytes long) is just the last two lines of the
> hexdump, and we can generate the public_key.pem from it, which is
>
> -BEGIN PUBLIC KEY-
> MCowBQYDK2VwAyEABER0VJXcFo38Kacis+vmWfXFrTgmbXLx7lMiMLyFSsU=
> -END PUBLIC KEY-
>
> We can also convert it to DER ($ openssl pkey -pubin -outform DER -out
> public_key.der), and here comes the problem: I tried to hash the DER file,
> and I got 141dcca6fea50f1c9f12c7150ca157a8e6e7bf7e79a6eb6f592a6235ab57ce23,
> which is different from what I see in DigiCert's certificate. Any ideas why
> this happened?
>
> Also, since the support of v2 .onion address will be removed from the Tor
> code base on July 15th, 2021 and v3 .onion address contains the full public
> key, I think it is meaningless to have 2.23.140.1.31 extension after that.
>
> Best,
> Xia
> ___
> 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

Questions About DigiCert .onion Certificate SubjectPublicKey Hash

2021-02-18 Thread SXIA via dev-security-policy 
Hello,

As required by CABForum guidelines, CAs must include the hash of an ASN.1 
SubjectPublicKey of the .onion service. For example, 
https://crt.sh/?id=3526088262 shows the SHA256 of the public key of 
archivev3qli37bju4rlh27glh24lljyezwxf4pokmrdbpefjlcrp5id.onion is 
08afa9604f4cd74a1a867f3ffcf61faacdb19785a9d4c378f72a54503f73dd65

Since this a v3 address, it is not difficult to extract the public key from 
.onion domain. Below is the hexdump of hs_ed25519_public_key

3d 3d 20 65 64 32 35 35  31 39 76 31 2d 70 75 62
6c 69 63 3a 20 74 79 70  65 30 20 3d 3d 00 00 00
04 44 74 54 95 dc 16 8d  fc 29 a7 22 b3 eb e6 59
f5 c5 ad 38 26 6d 72 f1  ee 53 22 30 bc 85 4a c5

So the public key (32 bytes long) is just the last two lines of the hexdump, 
and we can generate the public_key.pem from it, which is

-BEGIN PUBLIC KEY-
MCowBQYDK2VwAyEABER0VJXcFo38Kacis+vmWfXFrTgmbXLx7lMiMLyFSsU=
-END PUBLIC KEY-

We can also convert it to DER ($ openssl pkey -pubin -outform DER -out 
public_key.der), and here comes the problem: I tried to hash the DER file, and 
I got 141dcca6fea50f1c9f12c7150ca157a8e6e7bf7e79a6eb6f592a6235ab57ce23, which 
is different from what I see in DigiCert's certificate. Any ideas why this 
happened?

Also, since the support of v2 .onion address will be removed from the Tor code 
base on July 15th, 2021 and v3 .onion address contains the full public key, I 
think it is meaningless to have 2.23.140.1.31 extension after that.

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