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.
> 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 <
rob.st...@comodo.com> wrote:
>>
>> On 03/03/16 04:52,
sanja...@symantec.com wrote:
>>> On Wednesday, March 2, 2016 at 7:07:23 AM UTC-8, Rob Stradling wrote:
>> <snip>
>> <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