Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Neil Dunbar via dev-security-policy]

On 02/07/2020 13:31, Corey Bonnell via dev-security-policy wrote:
> Wouldn't adding the nocheck extension make the subCA certificate irrevocable, 
> thus in the case of a subCA certificate with serverAuth and ocspSigning EKUs, 
> violate the spirit (and maybe the wording?) of sections 4.9.7 and 4.9.10 of 
> the BRs, which mandate the availability of revocation services for the subCA 
> certificate?

I guess that you could still revoke via a CRL based mechanism.
id-pkix-ocsp-nocheck relevance seems limited to RFC 6960 Section
4.2.2.2.1. - I don't think it touches CRL interpretation.

However, I'm struggling to come up with a reason why one would want an
issuing CA which is also a delegated OCSP Responder for its issuing CA,
even if such a thing is RFC and BR compliant!

Regards,

Neil

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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Neil Dunbar via dev-security-policy]

On 02/07/2020 12:52, Pedro Fuentes via dev-security-policy wrote:
> If we look at the BR, it says:
> "[^**]: Generally Extended Key Usage will only appear within end entity 
> certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate 
> CAs MAY include the extension to further protect relying parties until the 
> use of the extension is consistent between Application Software Suppliers 
> whose software is used by a substantial portion of Relying Parties worldwide."
>
> Therefore, in my humble opinion it's fully logical to understand this 
> requirement "as it's written", which is to restrict the CA and protect 
> relying parties... In other words, the BR is clearly saying that the meaning 
> of the EKU in SubCAs MUST be understood as a constraint and NOT to express 
> the EKU of the certificate itself.

Pedro,

I think that the problem here isn't what the BRs indicate the reading of
EKUs in a CA certificate should be.

It's that RFC 6960 (Section 4.2.2.2) states that 

> OCSP signing delegation SHALL be designated by the inclusion of
>id-kp-OCSPSigning in an extended key usage certificate extension
>included in the OCSP response signer's certificate.


In other words, if a certificate X (CA or otherwise) contains that EKU
value, by definition, it becomes a valid delegated OCSP responder
certificate, regardless of the intentions surrounding EKU interpretation
in CA certificates. Thus, OCSP responses signed by that X, on behalf of
X's issuing CA, _would_ be properly validated by compliant RP software.
If a hostile party grabs hold of the private key for the CA certificate,
their harm is not limited to the PKI described by the original CA
certificate, but extends to all of the sibling certificates of X

Now, it's true that the BRs also require the id-pkix-ocsp-nocheck
extension too, but RFC 6960 does not require it (it's just the way to
say "trust this delegated cert for as long as it is valid", and don't
consult OCSP/CRLs).

Regards,

Neil

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

Re: GTS - OCSP serving issue 2020-04-09

[Neil Dunbar via dev-security-policy]

On 19/04/2020 11:13, Nick Lamb via dev-security-policy wrote:

On Sat, 18 Apr 2020 22:57:03 -0400
Ryan Sleevi via dev-security-policy
 wrote:


The Baseline Requirements address this. See 9.16.3 (particularly item
5) and 9.6.1 (6).

For better or worse, the situation is as Neil described and required
for all CAs.

It's possible that I'm confused somehow, but for me §9.16.3 of the BRs
does not have numbered item 5, and neither this nor §9.6.1 define
"contractual jeopardy" nor do they clear up why a subscriber would want
to shut down their service and perhaps be driven into bankruptcy in
deference to a mere technical error.


I suspect that this was a typo from Ryan, and he meant Section 9.6.3 (5) 
which states (regarding subscriber agreements) :


5. Reporting and Revocation: An obligation and warranty to: (a) 
promptly request revocation of the Certificate, and cease using it and 
its associated Private Key, if there is any actual or suspected misuse 
or compromise of the Subscriber’s Private Key associated with the 
Public Key included in the Certificate, and (b) promptly request 
revocation of the Certificate, and cease using it, if any information 
in the Certificate is or becomes incorrect or inaccurate.
Clause 6 of the same section is also relevant - (but only if the private 
key has been compromised):


6. Termination of Use of Certificate: An obligation and warranty to 
promptly cease all use of the Private Key corresponding to the Public 
Key included in the Certificate upon revocation of that Certificate 
for reasons of Key Compromise.


So, a CA is _required_ to have these terms in its Subscriber Agreements.

Regarding 9.6.1, you are right that my generic term (contractual 
jeopardy) is not defined, but it does establish that the Subscriber 
Agreement must be a legally enforceable document. If one party declines 
to adhere to its responsibilities under the agreement, the contract is 
placed in peril.


Now, if a CA is producing OCSP errors, or vague or confusing statements 
as to the status of one of its certificates, then absolutely a 
Subscriber would not shut down its services until the instruction from 
the CA is clearly expressed. My view is be that a properly formed, 
digitally signed and dated, statement of revocation _does_ make the 
instruction clear.


Regards,

Neil

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

Re: GTS - OCSP serving issue 2020-04-09

[Neil Dunbar via dev-security-policy]

On 17/04/2020 14:22, Nick Lamb via dev-security-policy wrote:

GOOD means_at least_  the good CertStatus (also 0) in OCSP. We'll see
why in a moment.


Fair enough. That's what I thought - so holding onto the last successful 
OCSP report you have, even if you get exception status codes thereafter 
is a good way forward. I think that's reasonable. I'm just less sure 
that you should be treating a well formed 'revoked' response as 
something which can be ignored until the current 'good' OCSP response 
expires. [Note my carefully chosen weasel words like 'well formed', 
which also entails stuff like proper timestamp checking etc, etc]. 
Ryan's writeup calls out the revoked situation under the heading of 
'make sure it is something the client will accept' - if the client 
understands OCSP responses at all, it needs to understand revoked, surely?



But why? We are us, why would we want to announce that our certificate
is revoked? What possible benefit could accrue to us from
choosing to do this?


Because it places you (a good actor) in compliance with your subscriber 
agreement? Just as an example, some text in a few commonly used CA 
Subscriber Agreements have subscriber obligations like "cease all use of 
the Certificate and its Private Key upon expiration or revocation of the 
Certificate" or "Subscriber shall promptly cease using a Certificate and 
its associated Private Key" (under the section for revocation). 
Presumably failure to adhere to that agreement could place you in some 
contractual jeopardy?


So, following from your response, I think that, indeed - shutting down 
the site until a replacement key/cert is deployed would be the 'right' 
thing to do, rather than advertise a revoked response. The difference 
being that shutting down is (usually) a manual step, whereas stapling 
the most recent valid response from the CA (good or revoked) is probably 
an automated step.


Regards,

Neil

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

Re: GTS - OCSP serving issue 2020-04-09

[Neil Dunbar via dev-security-policy]

On 16/04/2020 14:49, Kurt Roeckx via dev-security-policy wrote:

On 2020-04-16 14:56, Neil Dunbar wrote:


I would have thought that an OCSP-stapling implementation which got 
an OCSP status code 'successful' (0) with a 'revoked' status for the 
certificate would want to pass that on to the client, replacing any 
prior OCSP successful/status-good report, whether that prior report 
was still valid.


As owner of the certificate, I think you actually don't want to do 
that, because things will stop working. If it's revoked you want to 
get a new certificate, and as long as you don't have the new one, you 
want to use the old certificate and staple the good OCSP response.


Really? Continue to use a certificate in the (more recent) knowledge 
that the issuing CA has disavowed it? I know that will work from the 
perspective of the TLS protocol, but it might be the sort of thing which 
would run afoul of the owner's subscriber agreement. So, if the CA 
operated on a purely customer-enforced OCSP-stapling approach (ie, 
didn't publish the OCSP URI in the end certificate), that would mean the 
relying party would have no reasonable way to validate whether the 
certificate even _could_ be trusted.


I mean - I see what you're saying: you have a website which you want to 
keep working until you replace your certificate and/or private key. But 
if I had signed knowledge from the issuing CA that (for instance) my 
private key was compromised, I don't think it would be terribly ethical 
to continue its use; depending on your subscriber agreement it might not 
even be lawful. It seems like you are materially misrepresenting the 
state of your certificate to the detriment of your relying parties.


Regards,

Neil

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

Re: GTS - OCSP serving issue 2020-04-09

[Neil Dunbar via dev-security-policy]

On 16/04/2020 00:04, Nick Lamb via dev-security-policy wrote:

Specifically: You should cache your stapled GOOD answers in durable
storage if practical, and when periodically refreshing you should report
non-GOOD answers to the operator (e.g. logging them as an ERROR
condition) but always continue to present clients with the last GOOD
answer until it actually expires even if you receive newer non-GOOD
OCSP responses.


For the avoidance of doubt (and my own poor brain) - does 'GOOD' here 
mean OCSP status code 'successful' (0) AND returning a 'good' status for 
the certificate, or does it just mean status code 'successful'? The GTS 
case here was returning OCSP exception status 'unauthorized' (6).


I would have thought that an OCSP-stapling implementation which got an 
OCSP status code 'successful' (0) with a 'revoked' status for the 
certificate would want to pass that on to the client, replacing any 
prior OCSP successful/status-good report, whether that prior report was 
still valid.


But I'm with you on the implementation retaining the last successful 
OCSP report until it expires (I'd go further: if I got a 
successful/revoked response, followed by a successful/good response 
later on, I'd be flagging that to the CA as a serious problem, and 
retaining the successful/revoked ones until _it_ expires)


Cheers,

Neil

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

Re: DigiCert OCSP services returns 1 byte

[Neil Dunbar via dev-security-policy]

> On 24 Sep 2019, at 07:35, Clint Wilson via dev-security-policy 
>  wrote:
> 
> 
> […] it seems like one useful change for us
> here may be to issue those final certs without the SCTs rather than
> abandoning the pre-cert as we do today. We'd obviously still need to
> re-attempt issuance of another cert with the SCT list (as that's what a
> vast majority of customers expect), but reducing the number of orphaned
> pre-certs seems like a reasonably good thing, even if inconsequential for
> how we interact with the (pre-cert || cert).

Perhaps I’m misunderstanding, but wouldn’t the generation of a set of 
certificates (at least two in that set - one with SCTs embedded, and one 
without) end up with several certificates signed by the same Issuing CA, but 
with identical serial numbers? This would violate RFC 5280 Section 4.1.2.2. For 
publicly trusted CAs, a (pre-cert, cert) pair does not violate that condition 
by virtue of BR Section 7.1.2.5. Combining the two documents, it would seem 
that the number of certificates following a pre-certificate issuance is 
strictly limited to one.

Again - I may have misunderstood: apologies if this is the case - corrections 
welcome.

Regards,

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

Re: OCSP responder support for SHA256 issuer identifier info

[Neil Dunbar via dev-security-policy]

I think that, if the responder is capable of understanding another hash (e.g. 
SHA-256), and has support for that built into its backend database, returning 
the CertID with those supported hashes is fine and good. IMO, there should be 
no prohibition on supporting alternative hash algorithms.

But it stands to reason that the number of potential hash algorithms will 
generally be greater than the ability of OCSP responders to support them 
(especially in the case of CAs pregenerating responses); so the more general 
question seems to be “what is the optimal way to signal that the OCSP responder 
does not understand, or does not have a valid confirmation for, a given 
CertID.hashAlgorithm?”

Returning a response with an alternative CertID.hashAlgorithm (e.g. SHA-1) 
feels wrong; in order to validate the response, the client would have to 
recalculate the request using the “well known" hash algorithm - in which case, 
why didn’t it just send that query to the responder in the first place?

RFC 6960, Section 4.4.7.2.2 states "the responder SHOULD still use the
client request data during the selection of the pre-generated
response to be returned” - which would indicate that selection of an 
alternative CertID (even if semantically identical to the request) is viewed 
poorly.

“unauthorized” seems a valid view - it’s essentially saying “I don’t understand 
this Issuer specification”. Whether because of an unsupported hash algorithm, 
or a (name-hash, key-hash) value which does not map to a known issuer, it 
doesn’t really matter.

From my personal view, “malformedRequest” is also an acceptable return value - 
the text in RFC6960 gives the explanatory text “Illegal Confirmation Request” - 
which doesn’t in itself mean that the client sent a syntactically invalid OCSP 
request - merely that the parameters specified in that request cannot generate 
a successful answer from the OCSP responder.

So, from the original list of observed behaviours, 1, 4 and 5 seem OK by me.

Regards,

Neil

> On 19 Sep 2019, at 16:23, Curt Spann via dev-security-policy 
>  wrote:
> 
> I am looking at this from an interoperability perspective and not security. 
> If a client is requesting a SHA256 hash for the issuerNameHash and 
> issuerKeyHash I don’t think the OCSP responder should be prohibited from 
> returning a response containing issuerNameHash and issuerKeyHash using 
> SHA256. I like the idea of agility for algorithms and it appears the RFCs 
> supports this by having a CertID.hashAlgorithm field.
> 
> - Curt
> 
>> On Sep 19, 2019, at 4:24 AM, Rob Stradling via dev-security-policy 
>>  wrote:
>> 
>> I'm not aware of any requirement that demands that OCSP responders 
>> support SHA-256 for CertID.hashAlgorithm or of any requirement that 
>> forbids this.  Therefore, I think 1, 2 and 4 are all acceptable 
>> responses to an OCSP request whose CertID.hashAlgorithm is SHA-256.

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

Re: DigiCert OCSP services returns 1 byte

[Neil Dunbar via dev-security-policy]

> On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org 
> <mailto:dev-security-policy@lists.mozilla.org>> wrote:
> 
>> 
>> 
>>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> Hi Kurt.  I agree, hence why I proposed:
>>> 
>>>  "- I would also like to see BR 4.9.10 revised to say something roughly
>>> along these lines:
>>>   'If the OCSP responder receives a status request for a serial number
>>>that has not been allocated by the CA, then the responder SHOULD NOT
>>>respond with a "good" status.’"
>> 
>> I suppose one issue there is for CAs which allocate the serial number very
>> early on in the issuance workflow - signing a dummy certificate with an
>> untrusted key, for instance, but not committing the CA to actually
>> producing either a pre-certificate or certificate (e.g, because the
>> applicant has insufficient funds to complete the process). It would not
>> seem correct to start answering (affirmatively) OCSP requests where no
>> artefact has been signed by a trusted key.
>> 
> 
> Why does a CA need to sign something to allocate a serial? Could you expand
> a bit more on that?
> 

Yes - on further consideration, I could have been a lot clearer. I didn’t mean 
that a CA _has_ to sign something to allocate a serial in some internal 
database; merely that the allocation of a serial number, in itself, isn’t the 
trigger (in my opinion, of course) for any OCSP server to start responding to 
the (Issuer, Serial Number) request with successful response codes.

What I meant was that some workflows allocate a serial number, sign a dummy 
certificate containing that serial number (with an untrusted key), which then 
flows through with linting checks, and so on. But the decision to sign the said 
certificate with a trusted key has not yet been made (officially). But when any 
object (precertificate, certificate) containing that allocated serial number 
gets signed with a trusted key, it is a reasonable expectation for relying 
parties to be able to query OCSP services and not get a “Never heard of it” 
answer (whether that’s a RFC 6960 4.4.8 response, or an “unauthorized”, or 
whatever).

In other words, Rob’s original language which refers purely to the 
(CA-internal) allocation of the serial number as the triggering event seems not 
to cover all relevant cases. Not that I’ve been able to come up with any better 
language, I should add.

Regards,

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

Re: DigiCert OCSP services returns 1 byte

[Neil Dunbar via dev-security-policy]

> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy 
>  wrote:
> 
> Hi Kurt.  I agree, hence why I proposed:
> 
>   "- I would also like to see BR 4.9.10 revised to say something roughly
> along these lines:
>'If the OCSP responder receives a status request for a serial number
> that has not been allocated by the CA, then the responder SHOULD NOT
> respond with a "good" status.’"

I suppose one issue there is for CAs which allocate the serial number very 
early on in the issuance workflow - signing a dummy certificate with an 
untrusted key, for instance, but not committing the CA to actually producing 
either a pre-certificate or certificate (e.g, because the applicant has 
insufficient funds to complete the process). It would not seem correct to start 
answering (affirmatively) OCSP requests where no artefact has been signed by a 
trusted key.

It seems to me that the trigger point to start answering OCSP requests for a 
(Issuer, Serial Number) request would be when the serial number has been 
allocated AND an artefact has been signed by an issuer private key.

In other words, a CA might well allocate a serial number, which, if all goes 
well, will find its way into a certificate; but until a publicly trusted 
signature has been made on a TBSCertificate containing that serial number, an 
OCSP responder is behaving properly were it to answer “Never heard of that 
serial number for that Issuer”.

Regards,

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

Re: DigiCert OCSP services returns 1 byte

[Neil Dunbar via dev-security-policy]

> On 12 Sep 2019, at 18:46, Jeremy Rowley via dev-security-policy 
>  wrote:
> 
> The language says you have to provide the response for the cert as if it 
> exists, but the reality is that sending a response for the precert is the 
> same as calculating the result for the certificate as if it exists and 
> sending that. They are the same thing because the precert is treated the same 
> as the final cert if the final cert doesn’t exist.

I could be horribly mistaken, but I think Alex was asking is: in the event that 
precertificates are not signed by the issuing CA’s private key, but rather by a 
separate signing key/certificate dedicated to that purpose (per RFC 6962, 
Section 3.1) - is there then an obligation to provide OCSP services for that, 
given that the (name-hash, key-hash) on the OCSP request would not be the same 
as that which would normally obtain for the final certificate, which is signed 
directly by the issuing CA key?

It would _seem_ right that it should, since a pre-certificate could reasonably 
be revoked prior to issuing the final certificate, for several reasons. Yet 
it’s a reasonable follow-up question: would CAs who have such dedicated 
certificates make them available such that RPs could construct those OCSP 
requests?

> I believe the intent is that a CT-naïve OCSP checker would work normally when 
> presented with a precert or a certificate. Afterall, a precert is really just 
> a certificate with a special extension.

Would an OCSP server even be able to tell the difference? After all, it simply 
gets presented with a CA identifier (name-hash, key-hash) and a serial number. 
If it knows about that combination, it provides a response, but it’s got no way 
of knowing, absent extra information in its database whether the request 
pertains to a pre-cert or cert - in general. But see above for the case of 
dedicated precertificate signing certificates.

Regards,

Neil


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Neil Dunbar via dev-security-policy]

> On 30 Aug 2019, at 02:44, Kirk Hall via dev-security-policy 
>  > wrote:
> 
> OK, I'll try one last time to see if you are willing to share Google 
> information that you have with this group on the question at hand (Do browser 
> phishing filters and anti-virus apps use EV data in their anti-phishing 
> algorithms).  
> 
> This is super easy, and doesn't even require you to do any work, like 
> contacting Google Safe Browsing and asking them to participate in this 
> conversation.
> 
> Here's the question, and all I'm asking you to do is answer "Yes," "No," or 
> "I Don't Know"
> 
> **Based on your personal knowledge, does Google Safe Browsing use any EV 
> certificate Subject information in its anti-phishing algorithms?**

Kirk,

There is also the possibility that Ryan may have such knowledge, but absent 
permission from his employer, he is not at liberty to disclose internal company 
policies and procedures on an open forum. Indeed, it would not surprise me if 
this were the situation.

I’m not saying that this is the case, but merely to say that the Yes/No/IDK 
does not represent the full set of feasible responses.

Regards,

Neil

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

Misissuance Report: Incorrect CA-Issuers URI in some certificates

[Neil Dunbar via dev-security-policy]

To m.d.s.p,

The following contains an incident report, compiled as a result of the release 
of two example certificates with an incorrect CA-Issuers URI included.

Any questions or observations on this incident are gratefully received, and I 
will endeavour to answer them as quickly as I can.

Regards,

Neil Dunbar,
CA Administrator,
TrustCor Systems, S. de R.L.

—

1. How your CA first became aware of the problem (e.g. via a problem
  report submitted to your Problem Reporting Mechanism, a discussion in
  mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit),
  and the time and date.

2019-07-22 - 11:36:00 UTC - During TrustCor's post-issuance CT log
monitoring process, Internal QA identified two (2) certificates which
contained an incorrect URI value in the CA Issuers part of the
authorityInformationAccess extension.

2. A timeline of the actions your CA took in response. A timeline is a
  date-and-time-stamped sequence of all relevant events. This may include
  events before the incident was reported, such as when a particular
  requirement became applicable, or a document changed, or a bug was
  introduced, or an audit was done.

2019-07-22 - 11:36:00 UTC - TrustCor becomes aware of this issue.
2019-07-22 - 11:37:00 UTC - Certificate issuance for the ECA-1 CA hierarchy 
suspended, pending investigation of issue.
2019-07-22 - 11:42:45 UTC - Revocation of the two (2) affected certificates 
completed.
2019-07-22 - 11:45:00 UTC - TrustCor identified the problem - incorrect value 
stipulated for an Internal Example Certificate profile under the ECA-1 root (no 
other hierarchies shared this issue).
2019-07-22 - 11:50:00 UTC - Emergency Change Order completed, the profile 
values for ECA-1 internal example certificates corrected on testing and 
production platforms.
2019-07-22 - 11:52:00 UTC - Testing issuance now yields corrected certificates.
2019-07-22 - 11:56:00 UTC - TCPA granted permission to reissue corrected 
certificates.

3. Whether your CA has stopped, or has not yet stopped, issuing
  certificates with the problem. A statement that you have will be
  considered a pledge to the community; a statement that you have not
  requires an explanation.

TrustCor stopped issuing certificates identified with this problem and
rapidly resolved the issue.

4. A summary of the problematic certificates. For each problem: number
  of certs, and the date the first and last certs with that problem were
  issued.

Two (2) certificates were identified with this issue. The first was
issued at 2019-07-22 11:11:50 UTC, and the second (and last) was issued
at 2019-07-22 11:22:10 UTC.

5. The complete certificate data for the problematic certificates. The
  recommended way to provide this is to ensure each certificate is logged
  to CT and then list the fingerprints or crt.sh IDs, either in the report
  or as an attached spreadsheet, with one list per distinct problem.

Two (2) certificates were identified: one was revoked immediately post
production (as it is there to demonstrate a revoked certificate), and
the second certificate, which was otherwise valid, was then revoked
upon identifying the issue.

The crt.sh URIs for the certificates (now revoked) are:

https://crt.sh/?id=1695491402 
https://crt.sh/?id=1695520034 

6. Explanation about how and why the mistakes were made or bugs
  introduced, and how they avoided detection until now.

The problem was that the authorityInformationAccess CA-Issuers URI, (BR
Section 7.1.2.3, subsection c) was set to the Basic Secure Site CA
certificate, not the ECA-1 External CA certificate. While the BRs do not
actually mandate the inclusion of the CA-Issuers URI, providing an
incorrect value is certainly a mis-issuance.

When TrustCor CA created the new certificate profiles for the ECA-1 example
hierarchy, the profile QA tool previously only verified that the CA issuers
URI point to a valid TrustCor CA certificate.

Certificate profiles being copied from the test CA software are compared
with the intended profiles for production as part of the QA
process. Because the CA-Issuers URI is always different in test
vs. production, and the test URI domain is different from
production, the error was missed before the certificates were issued.

7. List of steps your CA is taking to resolve the situation and ensure
  such issuance will not be repeated in the future, accompanied with a
  timeline of when your CA expects to accomplish these things.

The profile QA tool has already been adjusted to ensure that the CA
Issuers URI points to a certificate within the allowed set of issuing
CAs for that profile. This should reduce the chances of this error
occurring again. Note that a profile could contain multiple potential
CAs (TrustCor CA's configuration is not so configured, but the EJBCA
software does permit such an arrangement).

We have updated our process to include an extra validation step, by
Internal QA, to confirm 

Incident Report: TrustCor Serial Number Entropy

[Neil Dunbar via dev-security-policy]

All,

Included is an incident report, formatted per the Mozilla recommendations, with 
timelines and resolutions.

Wayne - if you want to create a bug to track this, I’m happy to respond either 
there or here on m.d.s.p.

Regards,

Neil Dunbar
CA Administrator,
TrustCor Systems S. de R.L.
-

1. How your CA first became aware of the problem (e.g. via a problem
   report submitted to your Problem Reporting Mechanism, a discussion in
   mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit),
   and the time and date.

Following a recent discussion on mozilla.dev.security.policy [1], an incident 
was reported which led us to believe there could be an issue involving serial 
numbers in certificate issuance.

Specifically, the output of certificates would contain a 64-bit serial number, 
but depending on the software used, there is a high probability that the most 
significant bit (big-endian) of the serial numbers is 0. In this scenario, 
those certificate serial numbers would not meet Section 7.1 of the Baseline 
Requirements, having an effective entropy input of 63-bits.

This prompted us to perform an immediate investigation as to whether in our 
specific software configuration, sufficient entropy was being used in 
TrustCor's certificate serial number generation.


2. A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.

(All times are UTC)

[2019-02-25 08:25:00] TrustCor first becomes aware the potential issue.
[2019-02-25 09:25:00] TrustCor suspended issuance of all SSL certificates 
pending investigation.
[2019-02-25 13:00:00] Investigation into how to change serial number length, 
ideally on a per-CA basis.
[2019-02-26 15:30:00] TrustCor Policy Authority accepts that compliance is only 
guaranteed for at least 64-bit serial numbers, and orders identification and 
revocation of all certificates whose serial numbers contain less than the 
minimum required value, and a solution should to be found to reissue affected 
certificates and generate all future certificates with profiles greater than 
the required 64-bit.
[2019-02-27 18:05:00] Operational testing solution for 96-bit serial numbers 
successfully applied.
[2019-02-27 21:30:00] Downstream applications confirmed to function properly 
with larger serial numbers.
[2019-02-28 16:20:00] Risk acceptance performed into pushing the tested 
configuration into production. Change Approval Ticket generated.
[2019-02-28 20:17:32] Change Approval granted.
[2019-03-01 09:05:29] TrustCor identifies five (5) mis-issued certificates (all 
of which were internal certificates). All certificates identified as mis-issued 
are revoked.
[2019-03-01 09:30:00] Change to production issuance systems configuration 
complete.
[2019-03-01 11:14:00] Certificate issuance resumed, using larger entropy.
[2019-03-01 14:40:31] All revoked certificates are successfully reissued.
[2019-03-01 16:00:00] Verification that all certificate related services are 
working with the new serial numbers (CRLs, OCSP, CT publication, etc).

3. Whether your CA has stopped, or has not yet stopped, issuing
certificates with the problem. A statement that you have will be
considered a pledge to the community; a statement that you have not
requires an explanation.

When it became clear that there might have been a problem, TrustCor made the 
decision to suspend issuance until it could be established whether or not 
mis-issuance had taken place.

4. A summary of the problematic certificates. For each problem: number
of certs, and the date the first and last certs with that problem were
issued.

Five (5) valid (ie, unrevoked and unexpired) certificates were identified as 
exhibiting this problem. Three of the five certificates were TrustCor's own 
test website certificates. The other two were also owned by TrustCor for 
internal API websites. Once TrustCor identified a mis-issuance, all five of the 
mis-issued certificates were immediately revoked.

The first certificate with the problem was issued on 2017-11-30 22:01:39.

The last such certificate exhibiting the problem was issued on 2018-12-20 
12:53:05.

5. The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is logged
to CT and then list the fingerprints or crt.sh IDs, either in the report
or as an attached spreadsheet, with one list per distinct problem.

The certificates (now revoked) are:

https://crt.sh/?id=1044400819
https://crt.sh/?id=1044636961
https://crt.sh/?id=285016280
https://crt.sh/?id=295418448
https://crt.sh/?id=295418456

6. Explanation about how and why the mistakes were made or bugs introduced, and 
how they avoided detection until now.

It would appear that there was not general acceptance by 

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

> On 15 May 2018, at 07:59, Matthew Hardeman  wrote:
> 
> For that matter, can whoever is in charge of gmail.com  
> speak to their intent as to CAA for S/MIME?
> 
> I've certainly held certificates which include my personal gmail address 
> before.  At no point did I need or seek Google's blessing to do so.  I can 
> not imagine that was an uncommon case.  (At least, not uncommon relative to 
> the universe of issued S/MIME certificates.)

Well, I don’t see a CAA record for gmail.com , thus even if 
CAA issue tags were reinterpreted, as suggested, to cover S/MIME, such issuance 
would not be prohibited (unlike, say, google.com , which 
does have a CAA record).

In other words, those certificates that you were issued hitherto could not have 
violated CAA policy, since there was no such expression of policy.

Regards,

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

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

> On 15 May 2018, at 05:56, Ryan Sleevi  wrote:
> 
> No. I am expressly opposed to any solution that is “ask the big guys and let 
> them decide what it means for the Internet”.
> 
> While I can’t speak for Mozilla, that definitely seems against the spirit of 
> Mozilla’s principles of open and equal access.
> 
> It has a recasting failure mode as well, in that anyone who isn’t aware of 
> the subtlety of this proposed redefinition ends up less secure.
> 
> Surely you would agree that both of these consequences should be unacceptable?

Then it seems we are at an impasse. I am 100% in favour of allowing domain 
holders (defined broadly) being able to express policy via CAA (and since CAA 
tags are extensible, such policies have only just begun to be developed), I am 
not yet convinced that current CAA expressions intended to bind anything except 
TLS certificate issuance for end entities within the domain holders.

If I might rudely (and probably wrongly) paraphrase Tim, my opinion on what is 
or should be is all but irrelevant, if those are the facts on the ground.

I’m certainly not in favour of ‘ask the big players what it means’ if that 
means accepting everything they have to say as holy writ - but garnering 
expressions of intent, from a clearly impacted contingent, in order to better 
inform a debate, is not equivalent to that, to my way of thinking.

At the very least, Mozilla would want to publicise more widely the scope of any 
proposed reinterpretation of CAA records; having the reinterpretation happen 
within a relatively small, though not exclusive, conclave doesn’t seem like 
good policy.

Regards,

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

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

> On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
>  If there are proponents of a 'fail open' model,
> especially amongst CAs, then does it behove them to specify as quickly as
> possible a 'fail closed' model, so that we don't have to try and divine
> intent and second guess site operators as to whether they meant to restrict
> HTTPS or everything?

While this is in no way comprehensive or scientific, could we not just poll 
those (larger) domain owners who also operate publicly available mail services 
(like Yahoo) what they consider the scope of their CAA assertions? There can’t 
be a super abundance of them, surely?

I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of 
ninja-changing semantics either. If domain owners intended to only express a 
company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS or 
whatever); then might they not be amenable to altering their expression to an 
‘issue(wild)?-tls’ tag instead, but only if they were aware of the scope of 
their (in-)actions?

That would then enable a future move for CAs to respect ‘issue’ and ‘issuewild’ 
to cover all cert types, while still allowing domain owners finer grained 
expression of their policies. It’s pretty much an entire reversal of my earlier 
suggestion(!), but perhaps a modification which would preserve the expressions 
of (handwave, handwave) 95% of CAA records owners who don’t operate public mail 
services, and yet still can cover those mail providers?

But without the courtesy of at least asking those few domain owners what they 
meant, it just seems a bit rude to assume their intentions.

Regards,

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

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

But it also seems reasonable for organisations making CAA assertions to know 
the scope of their stipulations before they make them, no?

So, if in the case of Yahoo, they make the assertion “All of our web 
certificates should come from DigiCert”, are they aware that they are also 
making the statement “And all of our user mail accounts should only be granted 
S/MIME certificates from DigiCert too”.

Perhaps they are, perhaps not, but I’m willing to bet that a fair number of 
Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift to 
CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s 
customers.

Please note: I’m not opposed to CAA stipulations applying to S/MIME. I would 
just want all participants in the PKI world to know what their statements mean 
and how far they reach.

Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be 
restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean 
‘covering all possible forms of certificates’?

Just a thought,

Neil

> On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> It seems perfectly reasonable and desirable to require that CAs, regardless
> of the type of certificate they are issuing, respect CAA.
> 
> If an email provider wishes to restrict some types of certificates (e.g.
> HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
> additional expressions within the CAA syntax.
> 
> However, it would be a long-lasting, and tragic mistake if CAA was presumed
> to 'only' apply to HTTPS - because it would make the same mistake of
> nameConstraints - namely, everything that is not expressly listed as
> permitted/restricted is implicitly permitted - rather than doing what
> security practitioners have long known is the safe and secure base - forbid
> unless expressly permitted (default-deny).
> 
> In terms of order of concerns and constituents, the domain holders needs
> and security goals outweigh those of the notion of users 'owning' an email
> address.
> 
> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Just to say that looking at this from Europe, I don't see this feasible.
>> 
>> Citizens getting their personal eIDAS-compliant certificate go through
>> face-to-face validation and will give virtually any valid e-mail address to
>> appear in their certificate.
>> 
>> El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:
>>> I created a new issue suggesting that we add this requirement to Mozilla
>>> policy: https://github.com/mozilla/pkipolicy/issues/135
>>> 
>>> On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
 On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy <
 dev-security-policy@lists.mozilla.org> wrote:
 
> Hello,
> this question is somewhat outside the current Baseline Requirements,
 but...
> 
> wouldn't it be normal for the same CAA rules for server certificates
>> to
> also apply to client certificates when the email address is for a
>> domain
> that already has a valid CAA policy published in DNS?
> 
> 
> RFC 6844 doesn't seem to make any distinction between server and
>> S/MIME
> client certificates, it combines them together by referring to
 certificates
> "for that domain" as a whole.
> 
> 
> i tested this last night - i obtained an email certificate from one
>> of
 the
> CAs participating here (not for this exact address though) and it was
> happily issued even if CAA records authenticated by DNSSEC do not
>> allow
> their CA to issue for this domain.
> 
> Now, this is technically not a mis-issuance because it was a proper
> email-validated address and their CPS says that CAA is only checked
>> for
> server-type certificates. It doesn't say anything about CAA
>> validation
 for
> such client certificates.
> 
> I got in touch with them and they seemed equally surprised by such
> intended use case for CAA, so my second question is: is anyone
>> actually
> checking CAA records for client certificates where an email address
>> is
> included in the certificate subject info and the EKU includes Secure
 Email?
> 
> 
> Or is CAA usually checked only for server-type certificates, even if
>> RFC
> 6844 refers to certificates "for that domain" as a whole?
> 
 
 CAs are generally only checking CAA when they're required to in order
>> to be
 trusted.
 
 Right now, CAs are only required to check CAA for server-type
>> certificates
 (by virtue of the Baseline Requirements Section 3.2.2.8).
 CAs are not presently being required to check CAA for e-mail. They
>> can, but
 they are required to do it, so they are unlikely to do it.

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

Andrew,

SHA-1 has been removed from the TrustCor OCSP list of acceptable hash 
algorithms for responder signatures.

The minimum hash deemed acceptable now is SHA-256. We have updated the CP/CPS 
in section 6.1.5 to clarify that SHA-1 will no longer be honoured as a 
signature algorithm.

Best regards,

Neil Dunbar
TrustCor CA Administrator


> On 14 Aug 2017, at 20:48, Andrew Ayer via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> On Mon, 14 Aug 2017 20:27:05 +0100
> Neil Dunbar via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> 
>> Note that TrustCor is capable of removing SHA-1 as a signature hash on
>> OCSP responses, if the community determines it presents risk to the
>> relying parties. However, this does raise the risk to some clients
>> that would fail to understand the signature on the response.  We
>> should prefer to service as many clients as faithfully as we can while
>> remaining true to the security principles of this community.
> 
> Yes, OCSP responses signed with SHA-1 do present a risk, since a
> chosen prefix attack can be performed to forge OCSP responses and even
> certificates:
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02999.html
> 
> Even if you technically constrain your OCSP responder certificates as
> required by Mozilla policy section 5.1.1, forged OCSP responses are
> still possible if you use SHA-1.  That would allow attackers to use
> revoked certificates.  So it would be better if you didn't use SHA-1 at
> all for OCSP responses.
> 
> Thanks for your consideration of security feedback from the community.
> 
> Regards,
> Andrew
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



signature.asc
Description: Message signed with OpenPGP
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

Andrew,

Many thanks for reading and commenting on the policy documents. In
order to clarify and correct the issues which you highlight, new
versions (at version 1.3.2) of both CP and CPS have been published.

A summary of our actions follows. Paragraphs introduced with the text
"" indicate our response to the issues raised.

"*CP* (http://www.trustcor.ca/resources/cp.pdf)

1.6.3
1.6.4
Nit:
Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
TrustCor CA makes no authoritative statement, will have either the text “No
stipulation” or “Not Applicable”." but these sections are just blank."

 The References and Conventions sections in both the CP and CPS
documents have had the blank space replaced with "No Stipulation".

3.3.1
"Level 2 Client certificates - demonstration of a pre-shared key and OTP
validation as described in Section 3.2.3 is sufficient to allow re- key."
however section 3.2.3 makes no mention of pre-shared key and OTP validation.

Section 3.2.3 has been updated to explicitly mention the multi
factor authentication steps as mentioned in 3.3.1.

"4.4.2 Publication of the certificate by the CA
Note that is at odds with any future CT requirement."

This section of the CP has been replaced with one which
explicitly allows for publication to CT logs.

"6.1.5
"OCSP responses may respond using the SHA-1 hash if the request used
SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
(section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
TrustCor does not, and never has, used SHA-1 as a component of any
signature algorithm on a certificate."

It is our reading of the BRs that the use of SHA-1 as a
_certificate_ signature is forbidden (including for OCSP Responder
certificates);  not that such hashes are forbidden within the context
of OCSP Request/Response structure. Please note that our responder
_certificates_ do not use SHA-1, and never have. The text here only
mentions that signed OCSP responses (which have an maximum lifetime of
8 hours) may use SHA-1.

The text of this section has been revised to make completely clear
that the SHA-1 signature does NOT apply to responder certificates. It is
worth noting that section 4.3 of RFC 6960 states that OCSP clients SHOULD
be able to process such response signatures, indicating that such support
is to be reasonably expected.

Note that TrustCor is capable of removing SHA-1 as a signature hash on
OCSP responses, if the community determines it presents risk to the
relying parties. However, this does raise the risk to some clients
that would fail to understand the signature on the response.  We
should prefer to service as many clients as faithfully as we can while
remaining true to the security principles of this community.

"6.1.6
This section references version 1.3.0 of the BRs, which date from 2015."

 This oversight has been corrected, and refers to the controlling
version of the BRs stipulated in the document overview section (1.1).

*CPS* (http://www.trustcor.ca/resources/cps.pdf)

"1.4.1
The maximum validity of the different certificate types, while within
what's allowed by the BRs, aren't consistent with the limits specified in
section 6.3.2 of the CP (e.g. 12 months vs 398 days)."

The CP has been corrected to refer to number of days, so as to be
consistent across all documents.

"2.2
https://catest1-revoked.trustcor.ca/ is not resolving.
https://catest1-expired.trustcor.ca/ is not resolving.
https://catest2-revoked.trustcor.ca/ is not resolving.
https://catest2-expired.trustcor.ca/ is not resolving."

 The CPS has been updated to use the correct URIs, namely:

https://catest1-revoke.trustcor.ca/
https://catest1-expire.trustcor.ca/
https://catest2-revoke.trustcor.ca/
https://catest2-expire.trustcor.ca/

Note that the Self-Assessment documents contained these (correct) URIs
- this was an oversight stemming from a DNS change which should have
been reflected in the CPS.

"2.2.1
Commitment to make incident reports public - very good.
(Note that at the moment
https://www.trustcor.ca/resources/issuance-incidents/ currently just
redirects to the home page)"

The URI now resolves to the correct (albeit unpopulated) incident
page.

"3.2.2.4.7
Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
will *query* the authoritative DNS servers""

This has been corrected to include that word.

"3.2.6
While it's good that TrustCor will publish cross-signed certificates it
issues to other CAs, my understanding of section 3.2.6 of the BRs is that
it requires cross certifications that a CA obtains from other CAs (i.e.
where it is the Subject of the cert) to be published."

Section 3.2.6 has been updated to make clear that bilateral publication
is honoured. That is, if a TrustCor certificate is cross-signed by another
CA, then TrustCor will make such publication known, in its normal certificate
repository.

"4.9.1.1
Even though section 4.9.2 states that a subscriber can request revocation
of 

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

Andrew. 

Thank you for the review, comments and questions on TrustCor's policy 
documents.  

We are in the process of reviewing your comments and formulating a response to 
each.  We will provide our response and updates before EOB Tuesday, August 
15th, published to this discussion list.

Have a great weekend,

Neil Dunbar,
TrustCor CA Administrator

> On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy 
>  wrote:
> 
> Greetings,
> 
> I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
> following notes:
> 
> *CP* (http://www.trustcor.ca/resources/cp.pdf)
> 
> 1.6.3
> 1.6.4
> Nit:
> Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
> TrustCor CA makes no authoritative statement, will have either the text “No
> stipulation” or “Not Applicable”." but these sections are just blank.
> 
> 3.3.1
> "Level 2 Client certificates - demonstration of a pre-shared key and OTP
> validation as described in Section 3.2.3 is sufficient to allow re- key."
> however section 3.2.3 makes no mention of pre-shared key and OTP validation.
> 
> 4.4.2 Publication of the certificate by the CA
> Note that is at odds with any future CT requirement.
> 
> 6.1.5
> "OCSP responses may respond using the SHA-1 hash if the request used
> SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
> (section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
> TrustCor does not, and never has, used SHA-1 as a component of any
> signature algorithm on a certificate.
> 
> 6.1.6
> This section references version 1.3.0 of the BRs, which date from 2015.
> 
> *CPS* (http://www.trustcor.ca/resources/cps.pdf)
> 
> 1.4.1
> The maximum validity of the different certificate types, while within
> what's allowed by the BRs, aren't consistent with the limits specified in
> section 6.3.2 of the CP (e.g. 12 months vs 398 days).
> 
> 2.2
> https://catest1-revoked.trustcor.ca/ is not resolving.
> https://catest1-expired.trustcor.ca/ is not resolving.
> https://catest2-revoked.trustcor.ca/ is not resolving.
> https://catest2-expired.trustcor.ca/ is not resolving.
> 
> 2.2.1
> Commitment to make incident reports public - very good.
> (Note that at the moment
> https://www.trustcor.ca/resources/issuance-incidents/ currently just
> redirects to the home page)
> 
> 3.2.2.4.7
> Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
> will *query* the authoritative DNS servers"
> 
> 3.2.2.8
> Fail shut CAA - good
> 
> 3.2.6
> While it's good that TrustCor will publish cross-signed certificates it
> issues to other CAs, my understanding of section 3.2.6 of the BRs is that
> it requires cross certifications that a CA obtains from other CAs (i.e.
> where it is the Subject of the cert) to be published.
> 
> 4.9.1.1
> Even though section 4.9.2 states that a subscriber can request revocation
> of their certificate, 4.9.1.1 does not list a subscriber request as a
> reason for revocation.
> 
> 4.9.1.2
> I would like to hope that there are technical, not just business, controls
> in place to limit the actions an "insufficiently aware staff member" could
> perform.
> 
> 7.1.2.2
> Section 7.1.2.2 of the BRs states "certificatePolicies - This extension
> MUST be present and SHOULD NOT be marked critical." for Subordinate CA
> Certificates, however this section implies that certificatePolicies is only
> specified for Enterprise Subordinate CAs.
> 
> 7.1.2.3
> For the Secure Mail profiles, the subjectAlternativeName is defined as
> containing an "emailAddress". Should this not be rfc822Name?
> 
> 7.1.2.4
> It seems odd that this section references itself and 7.1.2.5.  Where these
> meant to be 7.1.2.2 and 7.1.2.3?
> 
> The CP requires the subject key identifier and authority key identifier
> extensions, but these are not specified in the cert profiles in the CPS.
> 
> 7.1.6.3
> This seems at odds with 7.1.2.2 of the BRs.
> 
> Those comments aside, I found both documents clear, well written, and they
> provided sufficient detail to assess the policies in place.
> 
> Many thanks,
> 
> Andrew
> ___
> 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: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

Andrew. 

Thank you for the review, comments and questions on TrustCor's policy 
documents.  

We are in the process of reviewing your comments and formulating a response to 
each.  We will provide our response and updates before EOB Tuesday, August 
15th, published to this discussion list.

Have a great weekend,

Neil Dunbar,
TrustCor CA Administrator

> On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy 
>  wrote:
> 
> Greetings,
> 
> I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
> following notes:
> 
> *CP* (http://www.trustcor.ca/resources/cp.pdf)
> 
> 1.6.3
> 1.6.4
> Nit:
> Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
> TrustCor CA makes no authoritative statement, will have either the text “No
> stipulation” or “Not Applicable”." but these sections are just blank.
> 
> 3.3.1
> "Level 2 Client certificates - demonstration of a pre-shared key and OTP
> validation as described in Section 3.2.3 is sufficient to allow re- key."
> however section 3.2.3 makes no mention of pre-shared key and OTP validation.
> 
> 4.4.2 Publication of the certificate by the CA
> Note that is at odds with any future CT requirement.
> 
> 6.1.5
> "OCSP responses may respond using the SHA-1 hash if the request used
> SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
> (section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
> TrustCor does not, and never has, used SHA-1 as a component of any
> signature algorithm on a certificate.
> 
> 6.1.6
> This section references version 1.3.0 of the BRs, which date from 2015.
> 
> *CPS* (http://www.trustcor.ca/resources/cps.pdf)
> 
> 1.4.1
> The maximum validity of the different certificate types, while within
> what's allowed by the BRs, aren't consistent with the limits specified in
> section 6.3.2 of the CP (e.g. 12 months vs 398 days).
> 
> 2.2
> https://catest1-revoked.trustcor.ca/ is not resolving.
> https://catest1-expired.trustcor.ca/ is not resolving.
> https://catest2-revoked.trustcor.ca/ is not resolving.
> https://catest2-expired.trustcor.ca/ is not resolving.
> 
> 2.2.1
> Commitment to make incident reports public - very good.
> (Note that at the moment
> https://www.trustcor.ca/resources/issuance-incidents/ currently just
> redirects to the home page)
> 
> 3.2.2.4.7
> Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
> will *query* the authoritative DNS servers"
> 
> 3.2.2.8
> Fail shut CAA - good
> 
> 3.2.6
> While it's good that TrustCor will publish cross-signed certificates it
> issues to other CAs, my understanding of section 3.2.6 of the BRs is that
> it requires cross certifications that a CA obtains from other CAs (i.e.
> where it is the Subject of the cert) to be published.
> 
> 4.9.1.1
> Even though section 4.9.2 states that a subscriber can request revocation
> of their certificate, 4.9.1.1 does not list a subscriber request as a
> reason for revocation.
> 
> 4.9.1.2
> I would like to hope that there are technical, not just business, controls
> in place to limit the actions an "insufficiently aware staff member" could
> perform.
> 
> 7.1.2.2
> Section 7.1.2.2 of the BRs states "certificatePolicies - This extension
> MUST be present and SHOULD NOT be marked critical." for Subordinate CA
> Certificates, however this section implies that certificatePolicies is only
> specified for Enterprise Subordinate CAs.
> 
> 7.1.2.3
> For the Secure Mail profiles, the subjectAlternativeName is defined as
> containing an "emailAddress". Should this not be rfc822Name?
> 
> 7.1.2.4
> It seems odd that this section references itself and 7.1.2.5.  Where these
> meant to be 7.1.2.2 and 7.1.2.3?
> 
> The CP requires the subject key identifier and authority key identifier
> extensions, but these are not specified in the cert profiles in the CPS.
> 
> 7.1.6.3
> This seems at odds with 7.1.2.2 of the BRs.
> 
> Those comments aside, I found both documents clear, well written, and they
> provided sufficient detail to assess the policies in place.
> 
> Many thanks,
> 
> Andrew
> ___
> 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: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

Andrew.

Thank you for the review, comments and questions on TrustCor's policy documents.

We are in the process of reviewing your comments and formulating a response to 
each.  We will provide our response and updates before EOB Tuesday, August 
15th, published to this discussion list.

Have a great weekend,

Neil Dunbar,
TrustCor CA Administrator

> On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy 
>  wrote:
> 
> Greetings,
> 
> I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
> following notes:
> 
> *CP* (http://www.trustcor.ca/resources/cp.pdf)
> 
> 1.6.3
> 1.6.4
> Nit:
> Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
> TrustCor CA makes no authoritative statement, will have either the text “No
> stipulation” or “Not Applicable”." but these sections are just blank.
> 
> 3.3.1
> "Level 2 Client certificates - demonstration of a pre-shared key and OTP
> validation as described in Section 3.2.3 is sufficient to allow re- key."
> however section 3.2.3 makes no mention of pre-shared key and OTP validation.
> 
> 4.4.2 Publication of the certificate by the CA
> Note that is at odds with any future CT requirement.
> 
> 6.1.5
> "OCSP responses may respond using the SHA-1 hash if the request used
> SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
> (section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
> TrustCor does not, and never has, used SHA-1 as a component of any
> signature algorithm on a certificate.
> 
> 6.1.6
> This section references version 1.3.0 of the BRs, which date from 2015.
> 
> *CPS* (http://www.trustcor.ca/resources/cps.pdf)
> 
> 1.4.1
> The maximum validity of the different certificate types, while within
> what's allowed by the BRs, aren't consistent with the limits specified in
> section 6.3.2 of the CP (e.g. 12 months vs 398 days).
> 
> 2.2
> https://catest1-revoked.trustcor.ca/ is not resolving.
> https://catest1-expired.trustcor.ca/ is not resolving.
> https://catest2-revoked.trustcor.ca/ is not resolving.
> https://catest2-expired.trustcor.ca/ is not resolving.
> 
> 2.2.1
> Commitment to make incident reports public - very good.
> (Note that at the moment
> https://www.trustcor.ca/resources/issuance-incidents/ currently just
> redirects to the home page)
> 
> 3.2.2.4.7
> Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
> will *query* the authoritative DNS servers"
> 
> 3.2.2.8
> Fail shut CAA - good
> 
> 3.2.6
> While it's good that TrustCor will publish cross-signed certificates it
> issues to other CAs, my understanding of section 3.2.6 of the BRs is that
> it requires cross certifications that a CA obtains from other CAs (i.e.
> where it is the Subject of the cert) to be published.
> 
> 4.9.1.1
> Even though section 4.9.2 states that a subscriber can request revocation
> of their certificate, 4.9.1.1 does not list a subscriber request as a
> reason for revocation.
> 
> 4.9.1.2
> I would like to hope that there are technical, not just business, controls
> in place to limit the actions an "insufficiently aware staff member" could
> perform.
> 
> 7.1.2.2
> Section 7.1.2.2 of the BRs states "certificatePolicies - This extension
> MUST be present and SHOULD NOT be marked critical." for Subordinate CA
> Certificates, however this section implies that certificatePolicies is only
> specified for Enterprise Subordinate CAs.
> 
> 7.1.2.3
> For the Secure Mail profiles, the subjectAlternativeName is defined as
> containing an "emailAddress". Should this not be rfc822Name?
> 
> 7.1.2.4
> It seems odd that this section references itself and 7.1.2.5.  Where these
> meant to be 7.1.2.2 and 7.1.2.3?
> 
> The CP requires the subject key identifier and authority key identifier
> extensions, but these are not specified in the cert profiles in the CPS.
> 
> 7.1.6.3
> This seems at odds with 7.1.2.2 of the BRs.
> 
> Those comments aside, I found both documents clear, well written, and they
> provided sufficient detail to assess the policies in place.
> 
> Many thanks,
> 
> Andrew
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



signature.asc
Description: Message signed with OpenPGP
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

> On 19 May 2017, at 10:24, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 18/05/17 23:40, Nick Lamb wrote:
>> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
>> here? Judging from self-assessment document, TrustCor's actual
>> practices are all intended to be 3.2.2.4 compliant (I will examine in
>> more detail later) but the language here suggests it might be
>> possible for applicants to successfully validate for DV by some other
>> means not listed in 3.2.2.4, which (again unless I'm mistaken)
>> Mozilla considers always to be mis-issuance.
> 
> As of 21st July 2017, yes :-) The language should be clear that only
> 3.2.2.4-conforming methods are allowed, and each documented method
> should say which subsection of 3.2.2.4 it is complying with.

The BR self assessment document (as well as the CPS) does indeed stipulate 
which of the 3.2.2.4 subsections are allowed in validation of a DV certificate. 
No methods outside of 3.2.2.4 are permitted. The WHOIS method mentioned here is 
allowed via BR 3.2.2.4.1. Note that not all of the allowed methods from the 
3.2.2.4 subsections are actually used by TrustCor. It is possible that the 
self-assessment summary might lead to the (incorrect) conclusion that methods 
other than 3.2.2.4 could be successful, but the TrustCor documents make clear 
that only 3.2.2.4 methods are allowed

With respect to the particular clause referring to WHOIS, from the current CPS:

"3.2.2.4.1 Validating the Applicant as a Domain Contact
TrustCor will use the WHOIS or RDAP protocols to gain the Domain
Registration document for the domain(s) being requested for certification.
The email address, name, physical address present in the WHOIS record
must match those details submitted as part of the application."

Regards,

Neil Dunbar
CA Administrator,
TrustCor Systems, S. de R.L.



signature.asc
Description: Message signed with OpenPGP
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy