BRs 8.7 Self-Audits - externalizable?

[Matthias van de Meent via dev-security-policy]

Hi,

BR section 8.7 (specifically the first paragraph) requires CAs to do a
self-audit at least every 3 months. Is this audit externalizable, e.g.
through hiring an audit firm to perform this 'self-audit', or must
this audit be done internally in the CA?
The wording implies 'internally', but by squinting my eyes it could
also be 'the CA can get anyone to do this audit[0], as long as it
happens'.

Most of the wordings date back to BR v1.0 (s 17.8) and BR v1.3.0,
making it difficult to find the rationales of that specific section.


-Matthias

[0] that is, minus the quarterly DTP audits, as those must be done by
a Validation Specialist (which must be 'employed by the CA', thus with
squinting technically could be a subcontractor?)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mandatory reasonCode analysis

[Ryan Sleevi via dev-security-policy]

On Wed, Sep 30, 2020 at 12:56 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > I also read this language:
> > If a CRL entry is for a Certificate not subject to these Requirements
> and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after
> 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
>
> I think "was either issued on-or-after 2020-09-30 or has a notBefore
> on-or-after 2020-09-30" is talking about "a Certificate not subject to
> these Requirements", not about when the CRL was issued.
>

Yes. Yet another reason I think our approach to stating requirements in
"plain English" does more harm than good.

The correct parse tree:
If a CRL entry is for:
  * a Certificate not subject to these Requirements; and
  * either:
* was issued on-or-after 2020-09-30; or
* has a notBefore on-or-after 2020-09-30
then:
  * the CRLReason MUST NOT be certificateHold (6).

This was hoped to be "obvious", given that a "CRL entry" (a specific thing
within a CRL, c.f. https://tools.ietf.org/html/rfc5280#section-5.3 and
X.509) is neither issued nor has a notBefore.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mandatory reasonCode analysis

[Rob Stradling via dev-security-policy]

Hi Doug.  I didn't filter by any CRL fields, as per option (2) in my original 
post.


From: Doug Beattie
Sent: Wednesday, September 30, 2020 17:53
To: Rob Stradling
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Mandatory reasonCode analysis

Hi Rob,

I'm not sure you filtered this report by "thisUpdate", maybe you did it by
nextUpdate by mistake?

The GlobalSign CRL on this report was created in 2016, thus the question.

Doug


-Original Message-
From: dev-security-policy  On
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 11:59 AM
To: dev-security-policy@lists.mozilla.org
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track
of reasonCodes, I thought I would conduct some analysis to determine the
level of (non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs
and OCSP responses with thisUpdate timestamps dated today or afterwards, or
if (2) every CRL and OCSP response currently being served by distribution
points and responders (regardless of the thisUpdate timestamps) is required
to comply.  (I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip
containing all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it, in
whole or in part without the express consent of the sender. Please notify
the sender by reply email, disregard the foregoing messages, and delete it
immediately.


___
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: Mandatory reasonCode analysis

[Jeremy Rowley via dev-security-policy]

That's probably true since CRL entries are published instead of issued and they 
don't have a notBefore date.

Regardless, I can see why someone would read it as requiring an update for all 
next published CRLs/OCSP given the historical way the BRs worked.

To be safe, we did update all of the DigiCert CRLs/OCSP for ICAs capable of 
issuing TLS. Looks like your report is flagging the legacy Symantec ICAs that 
are no longer trusted for TLS and are part of a root removal request.

From: Rob Stradling 
Sent: Wednesday, September 30, 2020 10:56 AM
To: Mozilla ; Jeremy Rowley 

Subject: Re: Mandatory reasonCode analysis

> I also read this language:
> If a CRL entry is for a Certificate not subject to these Requirements and was 
> either issued on-or-after 2020-09-30 or has a notBefore on-or-after 
> 2020-09-30, the CRLReason MUST NOT be certificateHold (6).

I think "was either issued on-or-after 2020-09-30 or has a notBefore 
on-or-after 2020-09-30" is talking about "a Certificate not subject to these 
Requirements", not about when the CRL was issued.


From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 on behalf of Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
Sent: 30 September 2020 17:41
To: Mozilla 
mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
Subject: RE: Mandatory reasonCode analysis

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


This is a good question. I read the requirements as applying only to CRLs and 
OCSP published after the effective date since the BRs always say explicitly 
when they apply to items before the effective date.

I also read this language:
If a CRL entry is for a Certificate not subject to these Requirements and was 
either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, 
the CRLReason MUST NOT be certificateHold (6).

Which made me think the language applied only to CRLs and OCSP issued after 
9-30. However, the language does only reference certificateHold and not the 
inclusion of reasonCode language.

That was the analysis I had anyway - that any CRLs and OCSP published after 
9-30 had to have  reasonCode.

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: 
dev-security-policy@lists.mozilla.org
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


___
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: Mandatory reasonCode analysis

[Rob Stradling via dev-security-policy]

> I also read this language:
> If a CRL entry is for a Certificate not subject to these Requirements and was 
> either issued on-or-after 2020-09-30 or has a notBefore on-or-after 
> 2020-09-30, the CRLReason MUST NOT be certificateHold (6).

I think "was either issued on-or-after 2020-09-30 or has a notBefore 
on-or-after 2020-09-30" is talking about "a Certificate not subject to these 
Requirements", not about when the CRL was issued.


From: dev-security-policy  on 
behalf of Jeremy Rowley via dev-security-policy 

Sent: 30 September 2020 17:41
To: Mozilla 
Subject: RE: Mandatory reasonCode analysis

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


This is a good question. I read the requirements as applying only to CRLs and 
OCSP published after the effective date since the BRs always say explicitly 
when they apply to items before the effective date.

I also read this language:
If a CRL entry is for a Certificate not subject to these Requirements and was 
either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, 
the CRLReason MUST NOT be certificateHold (6).

Which made me think the language applied only to CRLs and OCSP issued after 
9-30. However, the language does only reference certificateHold and not the 
inclusion of reasonCode language.

That was the analysis I had anyway - that any CRLs and OCSP published after 
9-30 had to have  reasonCode.

-Original Message-
From: dev-security-policy  On 
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: dev-security-policy@lists.mozilla.org
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


___
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: Mandatory reasonCode analysis

[Doug Beattie via dev-security-policy]

Hi Rob,

I'm not sure you filtered this report by "thisUpdate", maybe you did it by
nextUpdate by mistake?

The GlobalSign CRL on this report was created in 2016, thus the question.

Doug


-Original Message-
From: dev-security-policy  On
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 11:59 AM
To: dev-security-policy@lists.mozilla.org
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track
of reasonCodes, I thought I would conduct some analysis to determine the
level of (non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs
and OCSP responses with thisUpdate timestamps dated today or afterwards, or
if (2) every CRL and OCSP response currently being served by distribution
points and responders (regardless of the thisUpdate timestamps) is required
to comply.  (I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip
containing all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it, in
whole or in part without the express consent of the sender. Please notify
the sender by reply email, disregard the foregoing messages, and delete it
immediately.


___
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: Mandatory reasonCode analysis

[Jeremy Rowley via dev-security-policy]

This is a good question. I read the requirements as applying only to CRLs and 
OCSP published after the effective date since the BRs always say explicitly 
when they apply to items before the effective date.

I also read this language: 
If a CRL entry is for a Certificate not subject to these Requirements and was 
either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, 
the CRLReason MUST NOT be certificateHold (6).

Which made me think the language applied only to CRLs and OCSP issued after 
9-30. However, the language does only reference certificateHold and not the 
inclusion of reasonCode language. 

That was the analysis I had anyway - that any CRLs and OCSP published after 
9-30 had to have  reasonCode.  

-Original Message-
From: dev-security-policy  On 
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: dev-security-policy@lists.mozilla.org
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


___
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

Mandatory reasonCode analysis

[Rob Stradling via dev-security-policy]

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


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