On 04/03/16 04:18, Jeremy Rowley wrote:
If you recall, the fact that pre-certs are out of scope of the BRs was one of the reasons
against putting them into the BRs in the first place. The decision to add them was to
assist CAs who may have an overly strict reading on scope considering the very loose
language originally used: "These Requirements only address Certificates intended to
be used for authenticating servers accessible through the Internet." The fact the
BRs mention a document out of scope is not evidence of an intent to include them given
the history of that particular language.
Other comments:
"CT assists with "authenticating servers accessible through the Internet", because it helps
detect misissued certs. When CT is enforced, you can have increased confidence that the server you've
connected to is indeed "authentic"."
- Intending to assist is NOT the same thing as actually intending to
authenticate servers accessible through the Internet.
Neither certificates nor precertificates authenticate servers. Signed
blobs of data don't do anything! It's the TLS client code that actually
authenticates the server.
So, IMHO, if precertificates are out of scope, then certificates are out
of scope too.
"I think it's clear that precertificates _are_ "intended to be used for authenticating
servers accessible through the Internet" and that they are in-scope for the BRs."
- Completely disagree. I think it's clear they are NOT in scope...
We'll have to agree to disagree then.
but I would (as always) support a ballot to fix this. The BR scope is terrible
and really should be remedied.
+1. Let's make it so that there's no reason to disagree!
It's been a plague for over a year. I'm 100% supportive of any proposal to
include precerts and fix the language,
IIRC, all previous proposals for fixing the BR scope have focused on
features of the end-entity certificate profile. That's proved to be
problematic, because some CAs want/need to issue certs that could
technically be used for server authentication even though that's not the
intent (e.g. Subject.CN is included and EKU is required to be anyEKU).
Maybe we need to take a different approach that ignores the end-entity
certificate profile completely. How about we propose that...
- An X.509 certificate is in scope for the BRs if it's signed by an
Issuing CA that is in scope.
- An Issuing CA is in scope if:
i) it chains to a Root Certificate that is trusted for server
authentication
and
ii) there's no EKU "constraint" in that chain that excludes server
authentication.
and
iii) it hasn't been whitelisted by browsers as "out of scope".
?
but, given the current wording, I don't agree that Symantec violated any rule
the Forum has set.
-----Original Message-----
From: Rob Stradling [mailto:[email protected]]
Sent: Thursday, March 3, 2016 2:49 PM
To: Jeremy Rowley
Cc: [email protected]; [email protected]
Subject: Re: More SHA-1 certs
On 03/03/16 15:39, Jeremy Rowley wrote:
The RFC says "misissuance of a precertificate is considered equal to misissuance of
a final certificate". This raises an interesting question. Pre certificates are not
required to comply with the Cab forum's BRs as they fall out of scope (not intended to be
used for TLS authentication).
Jeremy, I have to disagree with you on that point.
The BRs say...
"7.1.2.5 Application of RFC 5280
For purposes of clarification, a Precertificate, as described in
RFC 6962 - Certificate Transparency, shall not be considered to
be a “certificate” subject to the requirements of RFC 5280 -
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile under these Baseline Requirements."
Precertificates must be in scope (for the BRs) for it to be within the BRs'
remit to declare them to be out of scope for RFC5280!
CT assists with "authenticating servers accessible through the Internet", because it
helps detect misissued certs. When CT is enforced, you can have increased confidence that the
server you've connected to is indeed "authentic".
I think it's clear that precertificates _are_ "intended to be used for
authenticating servers accessible through the Internet" and that they are in-scope
for the BRs.
Sha1 certs are only considered misissued because the BRs say issuance of a SHA1
certificate is prohibited. If the certificate is never issued, the misissuance
never occurred because the precertificate was not missused (no reqs against
SHA1 precerts) and a certificate in violation of the BRs was never created.
Rob Stradling <[email protected]> wrote:
On 03/03/16 04:52, [email protected] wrote:
On Wednesday, March 2, 2016 at 7:07:23 AM UTC-8, Rob Stradling wrote:
<snip>
I couldn't help but notice this SHA-1 precertificate issued by
Symantec a couple of days ago:
https://crt.sh/?id=13407116&opt=cablint
<snip>
Rob,
Sanjay, thanks for investigating.
This was a pre-certificate. Our systems do not allow issuance of SHA-1
certificates and no certificate was issued.
Were you aware that RFC6962 says that "misissuance of the
Precertificate is considered equal to misissuance of the final certificate"?
The pre-certificate was logged but then rejected. We are still investigating.
What do you mean by "...but then rejected"?
Serial number 64:a9:32:73:a4:19:d1:64:3f:6b:2d:a3:ca:97:f0:89 is not
currently listed on the CRL.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
