Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Tim Shirley via dev-security-policy]

That may well be the conclusion, that the benefits of total disclosure outweigh 
the costs in this type of scenario.  I just wanted to point out that there IS a 
cost to at least consider.  Yes, the certificate might have been seen in 
transmission between the CA and the customer, yes the customer might have made 
it public themselves, inadvertently or purposely.  I’m not saying there are any 
guarantees that only those 2 parties have seen it.  But suppose I visited that 
site and discovered the private key sitting there in the root directory before 
the certificate had been installed.  I *might* be able to get ahold of the cert 
to do bad things if it hasn’t been CT-logged, but I *definitely* can get ahold 
of it to do bad things if it has been.

From: Alex Gaynor 
Date: Friday, April 6, 2018 at 10:31 AM
To: Tim Shirley 
Cc: Jakob Bohm , 
"mozilla-dev-security-pol...@lists.mozilla.org" 

Subject: Re: Submission to ct-logs of the final certificate when there is 
already a pre-certificate

I think (3) shouldn't be considered any different from (1) -- they're only 
meaningfully different if you make a lot of assumptions about how it's stored 
and transported at every point from when the HSM signs the TBS to the 
certificates final resting place (on someone's disk? in their email inbox? in a 
sharepoint that's accidentally publicly accessible?). Once a cert has been 
issued, and even more so after it's been transmitted to the customer, we should 
not presume anything about how it's stored -- if only because that'd be a 
massive burden on CAs, for limited-to-no benefit.

Alex

On Fri, Apr 6, 2018 at 10:27 AM, Tim Shirley 
> wrote:
#2 seems like an obvious "no" to me as, at that point, you're only compounding 
a mistake and making that mistake actually usable in the public PKI if you 
proceed to issue the certificate.  In practice I can't imagine this scenario 
coming up much, but the policy shouldn't mandate doing this.

I think there's a third scenario to consider, and that is a case where the 
final certificate was issued but needed to be revoked prior to being put into 
service.  This might be because of mis-issuance, but it might just as easily be 
for another reason.  For example, after obtaining the certificate but before 
installing it, the requestor may discover that the private key had been exposed 
and thus want to get a new certificate with a different key.  If we required 
the final certificate to be CT-logged In that scenario, a certificate that was 
previously only known to the CA and the requestor would now be 
publicly-discoverable, and now the mandatory logging policy has made it easier 
for that exposed private key to be exploited.  So, while there are certainly 
advantages to indiscriminately logging all final certificates, there are 
downsides to weigh as well, at least for ones not (yet?) deployed on 
publicly-accessible web servers.

On 4/5/18, 3:08 PM, "dev-security-policy on behalf of Alex Gaynor via 
dev-security-policy" 

 on behalf of 
dev-security-policy@lists.mozilla.org>
 wrote:

There's two separable questions here:

1) Should CAs log final certificates after they issue a certificate with
embedded SCTs: My answer, yes.
2) Should CAs issue final certificates if they discover they are misissued
after logging the pre-certificate.

The answers to (1) and (2) do not need to be the same.

Alex

On Thu, Apr 5, 2018 at 3:05 PM, Jakob Bohm via dev-security-policy <

dev-security-policy@lists.mozilla.org>
 wrote:

> On 04/04/2018 04:27, Matt Palmer wrote:
>
>> On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via
>> dev-security-policy wrote:
>>
>>> On 02/04/2018 18:26, Tom Delmas wrote:
>>>
 Following the discussion on
 
https://scanmail.trustwave.com/?c=4062=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIpJG1bH1_Q=5=https%3a%2f%2fcommunity%2eletsencrypt%2eorg%2ft%2fnon-logging-of-final-cer
 tificates/58394

 What is the position of Mozilla about the submission to ct-logs of the
 final certificate when there is already a pre-certificate?

 As it helps discover bugs (
 

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Alex Gaynor via dev-security-policy]

I think (3) shouldn't be considered any different from (1) -- they're only
meaningfully different if you make a lot of assumptions about how it's
stored and transported at every point from when the HSM signs the TBS to
the certificates final resting place (on someone's disk? in their email
inbox? in a sharepoint that's accidentally publicly accessible?). Once a
cert has been issued, and even more so after it's been transmitted to the
customer, we should not presume anything about how it's stored -- if only
because that'd be a massive burden on CAs, for limited-to-no benefit.

Alex

On Fri, Apr 6, 2018 at 10:27 AM, Tim Shirley  wrote:

> #2 seems like an obvious "no" to me as, at that point, you're only
> compounding a mistake and making that mistake actually usable in the public
> PKI if you proceed to issue the certificate.  In practice I can't imagine
> this scenario coming up much, but the policy shouldn't mandate doing this.
>
> I think there's a third scenario to consider, and that is a case where the
> final certificate was issued but needed to be revoked prior to being put
> into service.  This might be because of mis-issuance, but it might just as
> easily be for another reason.  For example, after obtaining the certificate
> but before installing it, the requestor may discover that the private key
> had been exposed and thus want to get a new certificate with a different
> key.  If we required the final certificate to be CT-logged In that
> scenario, a certificate that was previously only known to the CA and the
> requestor would now be publicly-discoverable, and now the mandatory logging
> policy has made it easier for that exposed private key to be exploited.
> So, while there are certainly advantages to indiscriminately logging all
> final certificates, there are downsides to weigh as well, at least for ones
> not (yet?) deployed on publicly-accessible web servers.
>
> On 4/5/18, 3:08 PM, "dev-security-policy on behalf of Alex Gaynor via
> dev-security-policy"  trustwave@lists.mozilla.org on behalf of dev-security-policy@lists.
> mozilla.org> wrote:
>
> There's two separable questions here:
>
> 1) Should CAs log final certificates after they issue a certificate
> with
> embedded SCTs: My answer, yes.
> 2) Should CAs issue final certificates if they discover they are
> misissued
> after logging the pre-certificate.
>
> The answers to (1) and (2) do not need to be the same.
>
> Alex
>
> On Thu, Apr 5, 2018 at 3:05 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 04/04/2018 04:27, Matt Palmer wrote:
> >
> >> On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via
> >> dev-security-policy wrote:
> >>
> >>> On 02/04/2018 18:26, Tom Delmas wrote:
> >>>
>  Following the discussion on
>  https://scanmail.trustwave.com/?c=4062=l_
> TG2r42aQmbn72ySdqaNlBjW-xvJAqoIpJG1bH1_Q=5=https%3a%2f%2fcommunity%
> 2eletsencrypt%2eorg%2ft%2fnon-logging-of-final-cer
>  tificates/58394
> 
>  What is the position of Mozilla about the submission to ct-logs
> of the
>  final certificate when there is already a pre-certificate?
> 
>  As it helps discover bugs (
>  https://scanmail.trustwave.com/?c=4062=l_
> TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsVD1OD1_w=5=https%
> 3a%2f%2ftwitter%2ecom%2f%5fquirins%2fstatus%2f979788044994834434 ), it
> helps
>  accountability of CAs and it's easily enforceable, I feel that it
> should
>  be mandatory.
> 
> >>>
> >>> If such a policy were to be enacted, an alternative to submitting
> the
> >>> final certificate should be to revoke the certificate in both a
> >>> published CRL and in OCSP.  It would be counter to security to
> require
> >>> issuance in the few cases where misissuance is detected between CT
> >>> Pre-cert logging and actual issuance.
> >>>
> >>
> >> Logging the precert is considered demonstration of intent to issue,
> and is
> >> considered misissuance to the exact same degree as actually issuing
> the
> >> cert.  So revoke or whatever, you still done goofed, and so you
> should be
> >> checking for misissuance *before* you log the precert, not
> afterwards.
> >>
> >>
> > Of cause, I am just saying we should not force CAs to make a
> misissuance
> > worse in the rare cases where they /actually/ spot the mistake
> between
> > precert signing and actual cert signing.
> >
> > Remember, a precert generates only the danger that the cert might be
> > issued with an embedded CT proof, all other dangers only materialize
> if
> > and when the cert is actually issued.
> >
> >
> >
> > Enjoy
> >
> > Jakob
> > --
> > Jakob Bohm, CIO, Partner, WiseMo A/S.  https://scanmail.trustwave.
> 

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Tim Shirley via dev-security-policy]

#2 seems like an obvious "no" to me as, at that point, you're only compounding 
a mistake and making that mistake actually usable in the public PKI if you 
proceed to issue the certificate.  In practice I can't imagine this scenario 
coming up much, but the policy shouldn't mandate doing this.

I think there's a third scenario to consider, and that is a case where the 
final certificate was issued but needed to be revoked prior to being put into 
service.  This might be because of mis-issuance, but it might just as easily be 
for another reason.  For example, after obtaining the certificate but before 
installing it, the requestor may discover that the private key had been exposed 
and thus want to get a new certificate with a different key.  If we required 
the final certificate to be CT-logged In that scenario, a certificate that was 
previously only known to the CA and the requestor would now be 
publicly-discoverable, and now the mandatory logging policy has made it easier 
for that exposed private key to be exploited.  So, while there are certainly 
advantages to indiscriminately logging all final certificates, there are 
downsides to weigh as well, at least for ones not (yet?) deployed on 
publicly-accessible web servers.

On 4/5/18, 3:08 PM, "dev-security-policy on behalf of Alex Gaynor via 
dev-security-policy" 
 wrote:

There's two separable questions here:

1) Should CAs log final certificates after they issue a certificate with
embedded SCTs: My answer, yes.
2) Should CAs issue final certificates if they discover they are misissued
after logging the pre-certificate.

The answers to (1) and (2) do not need to be the same.

Alex

On Thu, Apr 5, 2018 at 3:05 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 04/04/2018 04:27, Matt Palmer wrote:
>
>> On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via
>> dev-security-policy wrote:
>>
>>> On 02/04/2018 18:26, Tom Delmas wrote:
>>>
 Following the discussion on
 
https://scanmail.trustwave.com/?c=4062=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIpJG1bH1_Q=5=https%3a%2f%2fcommunity%2eletsencrypt%2eorg%2ft%2fnon-logging-of-final-cer
 tificates/58394

 What is the position of Mozilla about the submission to ct-logs of the
 final certificate when there is already a pre-certificate?

 As it helps discover bugs (
 
https://scanmail.trustwave.com/?c=4062=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsVD1OD1_w=5=https%3a%2f%2ftwitter%2ecom%2f%5fquirins%2fstatus%2f979788044994834434
 ), it helps
 accountability of CAs and it's easily enforceable, I feel that it 
should
 be mandatory.

>>>
>>> If such a policy were to be enacted, an alternative to submitting the
>>> final certificate should be to revoke the certificate in both a
>>> published CRL and in OCSP.  It would be counter to security to require
>>> issuance in the few cases where misissuance is detected between CT
>>> Pre-cert logging and actual issuance.
>>>
>>
>> Logging the precert is considered demonstration of intent to issue, and 
is
>> considered misissuance to the exact same degree as actually issuing the
>> cert.  So revoke or whatever, you still done goofed, and so you should be
>> checking for misissuance *before* you log the precert, not afterwards.
>>
>>
> Of cause, I am just saying we should not force CAs to make a misissuance
> worse in the rare cases where they /actually/ spot the mistake between
> precert signing and actual cert signing.
>
> Remember, a precert generates only the danger that the cert might be
> issued with an embedded CT proof, all other dangers only materialize if
> and when the cert is actually issued.
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  
https://scanmail.trustwave.com/?c=4062=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsMQ0OCqrA=5=https%3a%2f%2fwww%2ewisemo%2ecom
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> 
https://scanmail.trustwave.com/?c=4062=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsAQ1rX1pw=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Jakob Bohm via dev-security-policy]

On 06/04/2018 03:04, Matt Palmer wrote:

On Thu, Apr 05, 2018 at 09:05:07PM +0200, Jakob Bohm via dev-security-policy 
wrote:

On 04/04/2018 04:27, Matt Palmer wrote:

On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via dev-security-policy 
wrote:

On 02/04/2018 18:26, Tom Delmas wrote:

Following the discussion on
https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394

What is the position of Mozilla about the submission to ct-logs of the
final certificate when there is already a pre-certificate?

As it helps discover bugs (
https://twitter.com/_quirins/status/979788044994834434 ), it helps
accountability of CAs and it's easily enforceable, I feel that it should
be mandatory.


If such a policy were to be enacted, an alternative to submitting the
final certificate should be to revoke the certificate in both a
published CRL and in OCSP.  It would be counter to security to require
issuance in the few cases where misissuance is detected between CT
Pre-cert logging and actual issuance.


Logging the precert is considered demonstration of intent to issue, and is
considered misissuance to the exact same degree as actually issuing the
cert.  So revoke or whatever, you still done goofed, and so you should be
checking for misissuance *before* you log the precert, not afterwards.


Of cause, I am just saying we should not force CAs to make a misissuance
worse in the rare cases where they /actually/ spot the mistake between
precert signing and actual cert signing.


Who is forcing CAs to misissue a certificate?




Hopefully no one.  I am just warning that a policy about CT logging of
certificates for which a pre-certificate has been CT logged needs to
be carefully phrased to avoid accidentally forcing CAs to misissue in
that situation.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Matt Palmer via dev-security-policy]

On Thu, Apr 05, 2018 at 09:05:07PM +0200, Jakob Bohm via dev-security-policy 
wrote:
> On 04/04/2018 04:27, Matt Palmer wrote:
> > On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via 
> > dev-security-policy wrote:
> > > On 02/04/2018 18:26, Tom Delmas wrote:
> > > > Following the discussion on
> > > > https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394
> > > > 
> > > > What is the position of Mozilla about the submission to ct-logs of the
> > > > final certificate when there is already a pre-certificate?
> > > > 
> > > > As it helps discover bugs (
> > > > https://twitter.com/_quirins/status/979788044994834434 ), it helps
> > > > accountability of CAs and it's easily enforceable, I feel that it should
> > > > be mandatory.
> > > 
> > > If such a policy were to be enacted, an alternative to submitting the
> > > final certificate should be to revoke the certificate in both a
> > > published CRL and in OCSP.  It would be counter to security to require
> > > issuance in the few cases where misissuance is detected between CT
> > > Pre-cert logging and actual issuance.
> > 
> > Logging the precert is considered demonstration of intent to issue, and is
> > considered misissuance to the exact same degree as actually issuing the
> > cert.  So revoke or whatever, you still done goofed, and so you should be
> > checking for misissuance *before* you log the precert, not afterwards.
> 
> Of cause, I am just saying we should not force CAs to make a misissuance
> worse in the rare cases where they /actually/ spot the mistake between
> precert signing and actual cert signing.

Who is forcing CAs to misissue a certificate?

- Matt

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

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Alex Gaynor via dev-security-policy]

There's two separable questions here:

1) Should CAs log final certificates after they issue a certificate with
embedded SCTs: My answer, yes.
2) Should CAs issue final certificates if they discover they are misissued
after logging the pre-certificate.

The answers to (1) and (2) do not need to be the same.

Alex

On Thu, Apr 5, 2018 at 3:05 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 04/04/2018 04:27, Matt Palmer wrote:
>
>> On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via
>> dev-security-policy wrote:
>>
>>> On 02/04/2018 18:26, Tom Delmas wrote:
>>>
 Following the discussion on
 https://community.letsencrypt.org/t/non-logging-of-final-cer
 tificates/58394

 What is the position of Mozilla about the submission to ct-logs of the
 final certificate when there is already a pre-certificate?

 As it helps discover bugs (
 https://twitter.com/_quirins/status/979788044994834434 ), it helps
 accountability of CAs and it's easily enforceable, I feel that it should
 be mandatory.

>>>
>>> If such a policy were to be enacted, an alternative to submitting the
>>> final certificate should be to revoke the certificate in both a
>>> published CRL and in OCSP.  It would be counter to security to require
>>> issuance in the few cases where misissuance is detected between CT
>>> Pre-cert logging and actual issuance.
>>>
>>
>> Logging the precert is considered demonstration of intent to issue, and is
>> considered misissuance to the exact same degree as actually issuing the
>> cert.  So revoke or whatever, you still done goofed, and so you should be
>> checking for misissuance *before* you log the precert, not afterwards.
>>
>>
> Of cause, I am just saying we should not force CAs to make a misissuance
> worse in the rare cases where they /actually/ spot the mistake between
> precert signing and actual cert signing.
>
> Remember, a precert generates only the danger that the cert might be
> issued with an embedded CT proof, all other dangers only materialize if
> and when the cert is actually issued.
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> 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: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Matt Palmer via dev-security-policy]

On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via dev-security-policy 
wrote:
> On 02/04/2018 18:26, Tom Delmas wrote:
> > Following the discussion on
> > https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394
> > 
> > What is the position of Mozilla about the submission to ct-logs of the
> > final certificate when there is already a pre-certificate?
> > 
> > As it helps discover bugs (
> > https://twitter.com/_quirins/status/979788044994834434 ), it helps
> > accountability of CAs and it's easily enforceable, I feel that it should
> > be mandatory.
> 
> If such a policy were to be enacted, an alternative to submitting the
> final certificate should be to revoke the certificate in both a
> published CRL and in OCSP.  It would be counter to security to require
> issuance in the few cases where misissuance is detected between CT
> Pre-cert logging and actual issuance.

Logging the precert is considered demonstration of intent to issue, and is
considered misissuance to the exact same degree as actually issuing the
cert.  So revoke or whatever, you still done goofed, and so you should be
checking for misissuance *before* you log the precert, not afterwards.

- Matt

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

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Jakob Bohm via dev-security-policy]

On 02/04/2018 18:26, Tom Delmas wrote:
Following the discussion on 
https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394


What is the position of Mozilla about the submission to ct-logs of the 
final certificate when there is already a pre-certificate?


As it helps discover bugs ( 
https://twitter.com/_quirins/status/979788044994834434 ), it helps 
accountability of CAs and it's easily enforceable, I feel that it should 
be mandatory.





If such a policy were to be enacted, an alternative to submitting the
final certificate should be to revoke the certificate in both a
published CRL and in OCSP.  It would be counter to security to require
issuance in the few cases where misissuance is detected between CT
Pre-cert logging and actual issuance.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Alex Gaynor via dev-security-policy]

Mozilla currently doesn't have any policy with respect to Certificate
Transparency, so I think diving in on this particular point is putting the
cart before the horse :-)

Currently Firefox does not check/require SCT presence nor does the Mozilla
root program require certificates to be logged.

Alex

On Mon, Apr 2, 2018 at 12:26 PM, Tom Delmas via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Following the discussion on https://community.letsencrypt.
> org/t/non-logging-of-final-certificates/58394
>
> What is the position of Mozilla about the submission to ct-logs of the
> final certificate when there is already a pre-certificate?
>
> As it helps discover bugs ( https://twitter.com/_quirins/s
> tatus/979788044994834434 ), it helps accountability of CAs and it's
> easily enforceable, I feel that it should be mandatory.
>
>
> ___
> 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

Submission to ct-logs of the final certificate when there is already a pre-certificate

[Tom Delmas via dev-security-policy]

Following the discussion on 
https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394


What is the position of Mozilla about the submission to ct-logs of the 
final certificate when there is already a pre-certificate?


As it helps discover bugs ( 
https://twitter.com/_quirins/status/979788044994834434 ), it helps 
accountability of CAs and it's easily enforceable, I feel that it should 
be mandatory.



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