Re: CA disclosure of revocations that exceed 5 days [Was: Re: Incident report D-TRUST: syntax error in one tls certificate]

[Ryan Sleevi via dev-security-policy]

On Fri, Nov 30, 2018 at 4:24 AM Dimitris Zacharopoulos 
wrote:

>
>
> On 30/11/2018 1:49 π.μ., Ryan Sleevi wrote:
>
>
>
> On Thu, Nov 29, 2018 at 4:03 PM Dimitris Zacharopoulos via
> dev-security-policy  wrote:
>
>> I didn't want to hijack the thread so here's a new one.
>>
>>
>> Times and circumstances change.
>
>
> You have to demonstrate that.
>
>
> It's self-proved :-)
>

This sort of glib reply shows a lack of good-faith effort to meaningfully
engage. It's like forcing the discussion every minute, since, yanno, "times
and circumstances have changed".

I gave you concrete reasons why saying something like this is a
demonstration of a weak and bad-faith argument. If you would like to
meaningfully assert this, you would need to demonstrate what circumstances
have changed in such a way as to warrant a rediscussion of something that
gets 'relitigated' regularly - and, in fact, was something discussed in the
CA/Browser Forum for the past two years. Just because you're unsatisfied
with the result and now we're in a month that ends in "R" doesn't mean time
and circumstances have changed meaningfully to support the discussion.

Concrete suggestions involved a holistic look at _all_ revocations, since
the discussion of exceptions is relevant to know whether we are discussing
something that is 10%, 1%, .1%, or .1%. Similarly, having the framework
in place to consistently and objectively measure that helps us assess
whether any proposals for exceptions would change that "1%" from being
exceptional to seeing "10%" or "100%" being claimed as exceptional under
some new regime.

In the absence of that, it's an abusive and harmful act.


> I already mentioned that this is separate from the incident report (of the
> actual mis-issuance). We have repeatedly seen post-mortems that say that
> for some specific cases (not all of them), the revocation of certificates
> will require more time.
>

No. We've seen the claim it will require more time, frequently without
evidence. However, I do think you're not understanding - there is nothing
preventing CAs from sharing details, for all revocations they do, about the
factors they considered, and the 'exceptional' cases to the customers,
without requiring any BR violations (of the 24 hour / 5 day rule). That CAs
don't do this only undermines any validity of the argument you are making.

There is zero legitimate reason to normalize aberrant behaviour.


> Even the underscore revocation deadline creates problems for some large
> organizations as Jeremy pointed out. I understand the compatibility
> argument and CAs are doing their best to comply with the rules but you are
> advocating there should be no exceptions and you say that without having
> looked at specific evidence that would be provided by CAs asking for
> exceptions. You would rather have Relying Parties loose their internet
> services from one of the Fortune 500 companies. As a Relying Party myself,
> I would hate it if I couldn't connect to my favorite online e-shop or bank
> or webmail. So I'm still confused about which Relying Party we are trying
> to help/protect by requiring the immediate revocation of a Certificate that
> has 65 characters in the OU field.
>
> I also see your point that "if we start making exceptions..." it's too
> risky. I'm just suggesting that there should be some tolerance for extended
> revocations (to help with collecting more information) which doesn't
> necessarily mean that we are dealing with a "bad" CA. I trust the Mozilla
> module owner's judgement to balance that. If the community believes that
> this problem is already solved, I'm happy with that :)
>

The argument being made here is as odious as saying "We should have one day
where all crime is legal, including murder" or "Those who knowingly buy
stolen goods should be able to keep them, because they're using them".

I disagree that CAs are "doing their best" to comply with the rules. The
post-mortems continually show a lack of applied best practice. DigiCert's
example is, I think, a good one - because I do not believe it's reasonable
for DigiCert to have argued that there was ambiguity, given that prior to
the ballot, it was agreed they were forbidden, a ballot to explicitly
permit them failed, and the discussion of that ballot explicitly cited why
they weren't valid. From that, several non-DigiCert CAs took steps to
migrate their customers and cease issuance. As such, you cannot reasonably
argue DigiCert was doing "their best", unless you're willing to accept that
DigiCert's best is, in fact, far lower than the industry norm.

The framing about "Think about harm to the Subscriber" is, again, one that
is actively harmful, and, as coming from a CA, somewhat offensive, because
it shows a difference in perspective that further emphasizes why CA's
judgement cannot be trusted. In this regard, we're in agreement that the
certificates we're discussing are clearly misissued - the CA was never
authorized to have issued that 

Re: Incident report D-TRUST: syntax error in one tls certificate

[Nick Lamb via dev-security-policy]

On Wed, 28 Nov 2018 22:41:37 +0100
Jakob Bohm via dev-security-policy
 wrote:

> I blame those standards for forcing every site to choose between two 
> unfortunate risks, in this case either the risks prevented by those 
> "pinning" mechanisms and the risks associated with having only one 
> certificate.

HTTPS Key Pinning (HPKP) is deprecated by Google and is widely
considered a failure because it acts as a foot-gun and (more seriously
but less likely in practice) enables sites to be held to ransom by bad
guys.

Mostly though, what I want to focus on is a big hole in your knowledge
of what's available today, which I'd argue is likely significant in
that probably most certificate Subscribers don't know about it, and
that's something the certificate vendors could help to educate them
about and/or deliver products to help them use.

> Automating certificate deployment (as you often suggest) lowers 
> operational security, as it necessarily grants read/write access to 
> the certificate data (including private key) to an automated, online, 
> unsupervised system.

No!

This system does not need access to private keys. Let us take ACME as
our example throughout, though nothing about what I'm describing needs
ACME per se, it's simply a properly documented protocol for automation
that complies with CA/B rules.

The ACME CA expects a CSR, signed with the associated private key, but
it does not require that this CSR be created fresh during validation +
issuance. A Subscriber can as they wish generate the CSR manually,
offline and with full supervision. The CSR is a public document
(revealing it does not violate any cryptographic assumptions). It is
entirely reasonable to create one CSR when the key pair is minted and
replace it only in a scheduled, predictable fashion along with the keys
unless a grave security problem occurs with your systems.

ACME involves a different private key, possessed by the subscriber/
their agent only for interacting securely with ACME, the ACME client
needs this key when renewing, but it doesn't put the TLS certificate key
at risk.

Certificates are public information by definition. No new risk there.


> Allowing multiple persons to replace the certificates also lowers 
> operational security, as it (by definition) grants multiple persons 
> read/write access to the certificate data.

Again, certificates themselves are public information and this does not
require access to the private keys.

> Under the current and past CA model, certificate and private key 
> replacement is a rare (once/2 years) operation that can be done 
> manually and scheduled weeks in advance, except for unexpected 
> failures (such as a CA messing up).
 
This approach, which has been used at some of my past employers,
inevitably results in systems where the certificates expire "by
mistake". Recriminations and insistence that lessons will be learned
follow, and then of course nothing is followed up and the problem
recurs.

It's a bad idea, a popular one, but still a bad idea.

> For example, every BR permitted automated domain validation method 
> involves a challenge-response interaction with the site owner, who
> must not (to prevent rogue issuance) respond to that interaction
> except during planned issuance.

It is entirely possible and theoretically safe to configure ACME
responders entirely passively. You can see this design in several
popular third party ACME clients.

The reason it's theoretically safe is that ACME's design ensures the
validation server (for example Let's Encrypt's Boulder) unavoidably
verifies that the validation response is from the correct ACME account
holder.

So if bad guys request issuance, the auto-responder will present a
validation response for the good guy account, which does not match and
issuance will not occur. The bad guys will be told their validation
failed and they've got the keys wrong. Which of course they can't fix
since they've no idea what the right ACME account private key is.

For http-01 at least, you can even configure this without the
auto-responder having any private knowledge at all. Since this part is
just playing back a signature, our basic cryptographic assumptions mean
that we can generate the signature offline and then paste it into the
auto-responder. At least one popular ACME client offers this behaviour.

For a huge outfit like Google or Facebook that can doubtless afford to
have an actual "certificate team" this would not be an appropriate
measure, but at a smaller business it seems entirely reasonable.


> Thus any unscheduled revalidation of domain ownership would, by 
> necessity, involve contacting the site owner and convincing them this
> is not a phishing attempt.

See above, this works today for lots of ACME validated domains.

> Some ACME protocols may contain specific authenticated ways for the
> CA to revalidate out-of-schedule, but this would be outside the norm.

Just revalidating, though it seems to be a popular trick for CAs, is
not 

Re: WISeKey - Request to transfer Root ownership to the OISTE Foundation

[Pedro Fuentes via dev-security-policy]

Hi Wayne,
thanks for your prompt reaction. I insert my comments below.

El jueves, 29 de noviembre de 2018, 19:01:16 (UTC+1), Wayne Thayer  escribió:
> Questions for OISTE/WISeKey:
> 
> Your plans for new audits will largely cover the requirement that OISTE
> demonstrate compliance with the entirety of our policy. I believe that you
> are asking for "approval" from Mozilla in the form of a "positive
> conclusion" to the public discussion prior to conducting those audits - is
> that correct? If so, I think that is a reasonable request. If the audits
> uncover problems, they can be addressed via our normal processes.

Yes, this is correct. We need to ensure full compliance with the Mozilla 
Program and therefore we'd process to execute the transfer plan only after 
having this approval.

> 
> Section 8.1 also states: "Mozilla MUST be notified of any resulting changes
> in the CA's CP or CPS." Are you able to tell us what those changes will be?
> I am understanding that OISTE would like to have Mozilla's "approval" prior
> to the change taking place, and thus the new CP/CPS taking effect, but I
> think it is reasonable for us to know the specifics of what changes are
> planned prior to ending this discussion period.
> 

Indeed there will be changes in the CP/CPS. I tried to explain this in the 
above request, but I'll provide here more details.

The current CPS is published by WISeKey and integrates the CP for the different 
certificate profiles issued. This CPS is already endorsed by the OISTE Policy 
Approval Authority (PAA), as explained in the first sections of the current 
CPS, because OISTE had always a role in our PKI (e.g. you can see in the Root 
Certificates the OU "OISTE Foundation Endorsed").
 
We already wanted time ago to separate the CPS into different CP and CPS 
documents, and we'll profit this transfer process to do a full refactor of the 
policies and practices documents.

The final picture we envision is:
* OISTE will publish a set of CP documents that regulate the different 
certificate types issued by the trust model. A priori I foresee a CP for 
personal certificates, another CP for SSL certificates and another CP for 
device certificates (IoT). OISTE will play a supervisory role to grant 
permission to a subordinate CA to adopt one or more CP and issue such types of 
certificates.
* OISTE will publish a CPS that covers the Root CAs and provides an "umbrella" 
for the whole trust model.
* WISeKey will publish at least one CPS that regulates the operation of the 
Issuing CAs, in accordance to the OISTE CPS and the CP implemented by these 
issuing CAs

Therefore a certificate subscriber will be still affected by the WISeKey CPS, 
as it is now, and our main intent will be that, in terms of "Certification 
practices", for the subscriber there won't be any practical change. It's just 
that, when evaluating our new practices, the readers will need to consider not 
only a single CPS document, but also the CP documents separately.

I think this change will be positive, because a CPS covering different types of 
certificate policies can end up by being complex to read, as it needs to 
contain all possibilities for identity validation, certificate profiles, etc. 
for certificate profiles that can be quite different, in a single CPS document. 
I think the new documentation framework will be clearer and more in line of the 
new best practices and requirements.

BTW, it happens that I'm member of the OISTE PAA, so I'll be personally 
involved in all the changes.

I hope this clarifies the question, but don't hesitate to ask for more 
information.

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

Re: CA disclosure of revocations that exceed 5 days [Was: Re: Incident report D-TRUST: syntax error in one tls certificate]

[Dimitris Zacharopoulos via dev-security-policy]

On 30/11/2018 1:49 π.μ., Ryan Sleevi wrote:



On Thu, Nov 29, 2018 at 4:03 PM Dimitris Zacharopoulos via 
dev-security-policy > wrote:


I didn't want to hijack the thread so here's a new one.


Times and circumstances change.


You have to demonstrate that.


It's self-proved :-)



When I brought this up at the Server
Certificate Working Group of the CA/B Forum
(https://cabforum.org/pipermail/servercert-wg/2018-September/000165.html),

there was no open disagreement from CAs. 



Look at the discussion during Wayne’s ballot. Look at the discussion 
back when it was Jeremy’s ballot. The proposal was as simplified as 
could be - modeled after 9.16.3 of the BRs. It would have allowed for 
a longer period - NOT an unbounded period, which is grossly negligent 
for publicly trusted CAs.


Agreed.



However, think about CAs that
decide to extend the 5-days (at their own risk) because of
extenuating
circumstances. Doesn't this community want to know what these
circumstances are and evaluate the gravity (or not) of the situation?
The only way this could happen in a consistent way among CAs would
be to
require it in some kind of policy.


This already happens. This is a matter of the CA violating any 
contracts or policies of the root store it is in, and is already being 
handled by those root stores - e.g. misissuance reports. What you’re 
describing as a problem is already solved, as are the expectations for 
CAs - that violating requirements is a path to distrust.


The only “problem” you’re solving is giving CAs more time, and there 
is zero demonstrable evidence, to date, about that being necessary or 
good - and rich and ample evidence of it being bad.


I already mentioned that this is separate from the incident report (of 
the actual mis-issuance). We have repeatedly seen post-mortems that say 
that for some specific cases (not all of them), the revocation of 
certificates will require more time. Even the underscore revocation 
deadline creates problems for some large organizations as Jeremy pointed 
out. I understand the compatibility argument and CAs are doing their 
best to comply with the rules but you are advocating there should be no 
exceptions and you say that without having looked at specific evidence 
that would be provided by CAs asking for exceptions. You would rather 
have Relying Parties loose their internet services from one of the 
Fortune 500 companies. As a Relying Party myself, I would hate it if I 
couldn't connect to my favorite online e-shop or bank or webmail. So I'm 
still confused about which Relying Party we are trying to help/protect 
by requiring the immediate revocation of a Certificate that has 65 
characters in the OU field.


I also see your point that "if we start making exceptions..." it's too 
risky. I'm just suggesting that there should be some tolerance for 
extended revocations (to help with collecting more information) which 
doesn't necessarily mean that we are dealing with a "bad" CA. I trust 
the Mozilla module owner's judgement to balance that. If the community 
believes that this problem is already solved, I'm happy with that :)




> Phrased differently: You don't think large organizations are
currently
> capable, and believe the rest of the industry should accommodate
that.

"Tolerate" would probably be the word I'd use instead of
"accommodate".


I chose accommodate, because you’d like the entire world to take on 
systemic risk - and it is indeed systemic risk, to users especially - 
to benefit some large companies.


Why stop with revocation, though? Why not just let CAs define their 
own validation methods of they think they’re equivalent? After all, if 
we can trust CAs to make good judgements on revocation, why can’t we 
also trust them with validation? Some large companies struggle with 
our existing validation methods, why can’t we accommodate them?


That’s exactly what one of the arguments against restricting 
validation methods was.


As I said, I think this discussion will not accomplish anything 
productive without a structured analysis of the data. Not anecdata 
from one or two incidents, but holistic - because for every 1 real 
need, there may have been 9,999 unnecessary delays in revocation with 
real risk.


How do CAs provide this? For *all* revocations, provide meaningful 
data. I do not see there being any value to discussing further 
extensions until we have systemic transparency in place, and I do not 
see any good coming from trying to change at the same time as placing 
that systemic transparency in place, because there’s no way to measure 
the (negative) impact such change would have.


I don't see how data and evidence for "all revocations" somehow makes 
things better, unless I misunderstood your proposal. It's not a balanced 
request. It would be a huge effort for CAs to write risk assessment 
reports for