Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Clint Wilson via dev-security-policy]

I think it makes sense to separate out the date for domain validation 
expiration from the issuance of server certificates with previously validated 
domain names, but agree with Ben that the timeline doesn’t seem to need to be 
prolonged. What about something like this:

1. Domain name or IP address verifications performed on or after July 1, 2021 
may be reused for a maximum of 398 days.
2. Server certificates issued on or after September 1, 2021 must have completed 
domain name or IP address verification within the preceding 398 days.

This effectively stretches the “cliff” out across ~6 months (now through the 
end of August), which seems reasonable.

Cheers!
-Clint

> On Feb 25, 2021, at 11:40 AM, Ben Wilson via dev-security-policy 
>  wrote:
> 
> Yes - I think we could focus on the domain validations themselves and allow
> domain validations to be reused for 398 days (maybe even from December 6,
> 2019), and then combine that with certificate issuance, but I'm not sure I
> like pushing this out to Feb 1, 2022 or even Oct. 1, 2021.  Maybe someone
> else on the list has a suggested formula?
> 
> On Thu, Feb 25, 2021 at 12:29 PM Doug Beattie 
> wrote:
> 
>> Ben,
>> 
>> I'd prefer that we tie this to a date related to when the domain
>> validations are done, or perhaps 2 statements.  As it stands (and as others
>> have commented), on July 1 all customers will immediately need to validate
>> all domains that were done between 825 and 397 days ago, so a huge number
>> all at once for web site owners and for CAs.
>> 
>> I'd prefer that it says " Domain validations performed from July 1, 2021
>> may be reused for a maximum of 398 days ".  I understand that this
>> basically kick the can down the road for an extra year and that may not be
>> acceptable, so, maybe we specify 2 dates:
>> 
>> 1)  Domain validations performed on or after July 1, 2021 may be reused
>> for a maximum of 398 days.
>> 
>> 2)  for server certificates issued on or after Feb 1, 2022, each dNSName
>> or IPAddress in a SAN must have been validated within the prior 398 days
>> 
>> Is that a compromise you could consider?
>> 
>> Doug
>> 
>> 
>> -Original Message-
>> From: dev-security-policy 
>> On Behalf Of Ben Wilson via dev-security-policy
>> Sent: Thursday, February 25, 2021 2:08 PM
>> To: Mozilla 
>> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
>> verification to 398 days
>> 
>> All,
>> 
>> I continue to move this Issue #206 forward with a proposed change to
>> section 2.1 of the MRSP (along with an effort to modify section 3.2.2.4 or
>> section 4.2.1 of the CA/B Forum's Baseline Requirements).
>> 
>> Currently, I am still contemplating adding a subsection 5.1 to MRSP section
>> 2.1 that would read,
>> " 5.1. for server certificates issued on or after July 1, 2021, verify
>> each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
>> or less;"
>> 
>> See draft language here
>> 
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/69bddfd96d1d311874c35c928abdfc13dc11aba3
>> 
>> 
>> Ben
>> 
>> On Wed, Dec 2, 2020 at 3:00 PM Ben Wilson  wrote:
>> 
>>> All,
>>> 
>>> I have started a similar, simultaneous discussion with the CA/Browser
>>> Forum, in order to gain traction.
>>> 
>>> 
>>> 
>>> https://lists.cabforum.org/pipermail/servercert-wg/2020-December/00238
>>> 2.html
>>> 
>>> Ben
>>> 
>>> On Wed, Dec 2, 2020 at 2:49 PM Jeremy Rowley
>>> 
>>> wrote:
>>> 
 Should this limit on reuse also apply to s/MIME? Right now, the 825
 day limit in Mozilla policy only applies to TLS certs with email
 verification of s/MIME being allowed for infinity time.  The first
 draft of the language looked like it may change this while the newer
 language puts back the TLS limitation. If it's not addressed in this
 update, adding clarification on domain verification reuse for SMIME
 would be a good improvement on the existing policy.
 
 -Original Message-
 From: dev-security-policy
 
 On Behalf Of Ben Wilson via dev-security-policy
 Sent: Wednesday, December 2, 2020 2:22 PM
 To: Ryan Sleevi 
 Cc: Doug Beattie ; Mozilla <
 mozilla-dev-security-pol...@lists.mozilla.org>
 Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain
 name verification to 398 days
 
 See my responses inline below.
 
 On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi  wrote:
 
> 
> 
> On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> See responses inline below:
>> 
>> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie
>> >> 
>> wrote:
>> 
>>> Hi Ben,
>>> 
>>> For now I won’t comment on the 398 day limit or the date which
>>> you
>> propose
>>> this to take effect (July 1, 2021), but on the ability of CAs to
>>> re-use domain validations completed prior to 1 July for 

Re: About upcoming limits on trusted certificates

[Clint Wilson via dev-security-policy]

Hi Matt,

This is determined using the notBefore value in the certificate; if the 
notBefore value is greater than or equal to September 1, 2020 00:00 GMT/UTC, 
then the updated policy will apply.

Cheers,
-Clint

> On Mar 3, 2020, at 1:41 PM, Matt Palmer via dev-security-policy 
>  wrote:
> 
> On Tue, Mar 03, 2020 at 11:55:24AM -0800, Clint Wilson via 
> dev-security-policy wrote:
>> For additional information, please see 
>> https://support.apple.com/en-us/HT211025.
> 
> I have a question regarding this part:
> 
>> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC
>> must not have a validity period greater than 398 days.
> 
> How is Apple determining when a certificate was issued?  That's
> traditionally been pretty tricky to determine, exactly, so I'm curious to
> know how Apple has solved it.
> 
> - Matt
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

About upcoming limits on trusted certificates

[Clint Wilson via dev-security-policy]

Hello all,

I wanted to inform this community of an upcoming change to the Apple Root 
Program. 
SSL/TLS certificates issued on or after September 1, 2020 will need to have a 
total lifetime of no more than 398 days. This change will be put in place in a 
future release of iOS, macOS, iPadOS, watchOS, and tvOS for default-trusted TLS 
certificates (i.e. the Roots that come preinstalled on the above OSes).

For additional information, please see https://support.apple.com/en-us/HT211025.

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

Re: DNS records and delegation

[Clint Wilson via dev-security-policy]

On Thu, Oct 10, 2019 at 11:32 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Oct 10, 2019 at 11:42 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Question, is there any prohibition against demonstration of domain
> control
> > being delegated to a third party or even the CA itself? I don't think so,
> > but figured we've discussed differences in interpretation a lot lately so
> > wanted to see if people agreed.
> >
>
> Huge thanks for bringing this up early :) Definitely the example for all
> CAs :)
>

Thank you for the response, insight, and feedback here! Really, really
helpful in clarifying some of the open questions/discussions we've been
having.


>
> That said, you probably could have worded better, "demonstration of domain
> control being delegated to a third party" is... probably not the best way
> of framing ;)
>
>
> > I mean, the obvious issue is the customer.com domain would need to want
> > to delegate this domain.com. But if you had a pretty non-technical
> person
> > operating the DNS, they could set it to the domain.com name and leave
> > their DNS settings forever.
> >
> > This looks allowed under the BRs, but should it be? Or is it like key
> > escrow - okay if a reseller does it (but frowned upon). Totally not cool
> if
> > the CA does it.
> >
>
> This is definitely a good way of looking at it!
>
> I'm familiar with at least one CA using an approach like this - Amazon
> Trust Services, with
> https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html
> .
> There's subtlety here, though, which is why I like how you drew the
> comparison to key escrow.
>
> On first glance, it seems Amazon Trust Services is issuing certificates to
> Amazon Web Services, both (through a complex structure) Affiliates, on
> behalf of the user. And so it might seem that the user is pointing their
> DNS to the CA, and that's how it's working.
>
> However, when you look through the CCADB disclosures, along with the
> certificates actually issued, it's clearer that the user is pointing those
> records to Amazon Web Services, but the actual issuing CA is DigiCert (as
> disclosed at https://www.amazontrust.com/repository/ ). It's also the case
> that, if you look at how things are setup, the domain holder isn't the one
> applying for the certificate - it's Amazon Web Services applying for the
> certificate (i.e. they are the Applicant, not the domain owner), and AWS
> configuring their own DNS records to contain a random value, to demonstrate
> to the CA (DigiCert) that AWS, the Applicant, is authorized for the domain.
>
> It's a really elegant solution, but it turns out it's not a "CA
> self-dealing" kind of thing, which would have been useful as an example if
> it was already allowed.
>
> Now let's discuss how this idea could all go wrong, because it teases out a
> little why the question of who is Applicant is relevant and important to
> understanding.
>
> Let's imagine that I setup the following (and I'm going to butcher this
> pseudo-code, so bear with me)
> _validation.sleevi.example 3600 IN CNAME .ca.example
> .ca.example 1 IN CNAME .random.ca.example
> .random.ca.example 1 IN TXT "{the CA challenge goes here}"
>
> Now, whenever the CA receives a request to validate "sleevi.example", they
> map that to a domain-id. They then update the CNAME, and the TXT record, to
> match the CA-defined challenge value. Then, they issue a TXT record lookup
> for _validation.sleevi.example, get the challenge value back, and huzzah,
> the cert is authorized!
>
> But there's a small problem with this. Who was the Applicant requesting
> sleevi.example? From the CA's perspective, how does it distinguish me, the
> legit domain holder, from 'evil hacker'? In the Amazon case, AWS is the
> Applicant, and AWS is the one doing this fancy DNS stuff, so it's clear -
> only AWS can do this, and they're who the user delegated to.
>
> However, if the "party doing this domain dance" is != "the applicant", then
> a lot can go wrong here, because they might do the dance for two different
> applicants. The easiest example would be if the CA, for every CSR it
> received, regardless of the Applicant, it updated the  for
> sleevi.example - at that point, anyone in the world could get a cert for my
> domain from that CA, and that would not be the good result.
>

Apologies, but this isn't entirely clear to me. I'm guessing (hoping) my
misunderstanding centers around a difference between the Applicant fully
delegating DNS to the CA vs the Applicant only configuring a single CNAME
record? If the Applicant has configured
_validation.sleevi.example 3600 IN CNAME .ca.example
then the CA wouldn't be able to use any other  value to complete
the full lookup to include the TXT record, without the Applicant directly
changing the CNAME value.

However, if the CA is fully managing this DNS, and therefore able to
independently reconfigure:

Re: DigiCert OCSP services returns 1 byte

[Clint Wilson via dev-security-policy]

On Wed, Sep 25, 2019, 06:30 Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > On 24 Sep 2019, at 07:35, Clint Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> 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


Sorry, I think the misunderstanding is my fault. You're correct if the same
pre-cert was used for two subsequent leaf signings.
What I meant was where now we would abandon retrying signing of the leaf
due to failure in retrieval of the SCTs, we would instead sign the leaf
without SCTs, then start the entire process over again once CT logs were
available (new tbsCert, new pre-cert, new leaf).
So same subject/sAN contents, but not the same serial number.

Cheers!
Clint
___
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

[Clint Wilson via dev-security-policy]

On Tue, Sep 24, 2019 at 5:06 AM Ryan Sleevi  wrote:

>
>
> On Tue, Sep 24, 2019 at 2:36 AM Clint Wilson  wrote:
>
>> On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> Agreed especially with the final paragraph here.
>> Apologies if this is too tangential, but one potential change I see
>> coming out of this discussion is around CT Log "outages". That is, separate
>> from the misconfiguration issues we've seen, one other instance where
>> sometimes pre-certificates are generated without an associated certificate
>> is when CT logs necessary for meeting a browser CT policy aren't available
>> (as Andy points out). Even if for very brief windows, today we occasionally
>> see windows where quite a few pre-certs can be generated but final
>> certificate issuance abandoned due to lack of SCTs (which is purely an
>> implementation choice as to when to abandon retries, I think).
>>
>
> Right. I think that's the substance of it. It's unclear to me what the
> benefit is of abandoning versus retrying later. I suspect it's a question
> of what the CA's window would be for (validation + SCTs), and if it's
> easier to kick it back into a validation flow if the SCT window elapses.
> Does that guess sound right?
>

Yeah, that's exactly right. That's also partially because we don't cache
CAA for 8 hours, so we could instead widen the window of retries as well.

>
>
>> Thinking through this discussion, 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). Does that seem like a
>> reasonable change in process to make?
>>
>
> It's not clear to me why this would be good or desirable? It doesn't seem
> to benefit the client/relying party ecosystem any. And it seems like it'd
> be more work for the CA to do.
>
> Perhaps I'm just not familiar with the set of CA problems it would solve?
> Could you help me out?
>

So I'm not totally confident that it is good or desirable, but my thought
was more along the lines of cognitive benefits than operational. It's
apparently somewhat difficult to grok that "cert" interactions need to
apply to pre-certs, so if CAs moved away from abandoning pre-certs
(wherever possible), then a lot of the behavior changes discussed here
would happen automatically. That is, we have to put in a fix for ensuring
services are available either way for (pre-certs || certs), but if there is
more reliably (pre-cert && cert) available then the services are (from what
I can see) already available for CAs. Maybe that's a change that can occur
ahead of patches for the misconfiguration issues.
Since all of that's relatively short-term benefits, I'm probably not
approaching this the best way, but that was the thought.
___
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

[Clint Wilson via dev-security-policy]

On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Sep 23, 2019 at 11:53 PM Andy Warner via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > The practice of revoking non-issued certificates would therefore lead to
> > CRL growth which would further make reliable revocation checking on
> > bandwidth constrained clients more difficult.
>
>
> As others have pointed out, it sounds like GTS is confused. This only
> applies if you need to revoke them.
>
> I’m not sure how many times it bears repeating, but the suggestion that you
> need to revoke if you issued a precert, but not the cert, is patently
> absurd. Among other things, as you point out, it causes both CRL and OCSP
> growth.
>
> Luckily, every browser participating has seemingly tried to make it clear
> that’s not expected. So one objection handled :)
>
> 2. There seem to be a number of assumptions that precertificate issuance
> > and certificate issuance is roughly atomic. In reality, a quorum of SCTs
> is
> > required prior to final certificate issuance, so that is not the case.
>
>
> Could you point to an example? All of the conversation I’ve seen has
> highlighted that they are sequential, and can suffer a variety of delays or
> errors. This is why the conversation has been about the least error prone
> approach, in that it leads to the most consistent externally observable
> results.
>
> I admit, I’m honestly not sure what part of the conversation is being
> referred to here.
>
> As a result of this, the existence of a precertificate is possible without
> > a final certificate having been issued.
>
>
> Yup. And it’s been repeatedly acknowledged that is perfectly fine. The
> proposed language further considers that, but emphasizes that by producing
> and logging the precertificate, then regardless of the issue, the CA should
> be prepared to provision services for it for the duration.
>
> If you find yourself continually generating precertificates, that suggests
> an operational/design issue, which you can remediate based on which is
> cheaper for you: fixing the pipeline to be reliable (as many reliability
> issues seen, to date, have been on the CA side) or continue to provision
> services when things go bad. Either works, you can choose.
>
> The important part is you need to treat (pre-cert || cert) in scope for all
> your activities. You must be capable of revoking. You must be capable of
> searching your databases. You must be capable of validating.
>

Agreed especially with the final paragraph here.
Apologies if this is too tangential, but one potential change I see coming
out of this discussion is around CT Log "outages". That is, separate from
the misconfiguration issues we've seen, one other instance where sometimes
pre-certificates are generated without an associated certificate is when CT
logs necessary for meeting a browser CT policy aren't available (as Andy
points out). Even if for very brief windows, today we occasionally see
windows where quite a few pre-certs can be generated but final certificate
issuance abandoned due to lack of SCTs (which is purely an implementation
choice as to when to abandon retries, I think).
Thinking through this discussion, 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). Does that seem like a
reasonable change in process to make?


>
> 3. This raises the question of how much time a CA has from the time they
> > issue a precertificate to when the final certificate must be issued.
>
>
> It doesn’t, because it’s a flawed understanding that’s been repeatedly
> addressed: you don’t have to issue the final certificate. But you MUST be
> prepared to provision services as if you had.
>
> In general, this means you provision and distribute those services ahead of
> time. My reply to Dimitris earlier today provided a road map to an error
> prone design, as well as two different ways of accomplishing compliant
> design. Given that GTS is responding to that thread, I’m surprised to see
> it come up again so quickly, as it seems like GTS may not have understood?
>
>
> Likewise, there is the question of how soon the revocation information must
> > be produced and reachable by an interested party (e.g. someone who has
> > never seen the certificate in question but still wants to know the status
> > of that certificate). [Aside, Wayne, you specifically said relying
> parties
> > earlier, did you intend to say interested party or relying party? We have
> > some additional questions if relying party was actually intended, as
> using
> > 

Re: Mozilla cert report - am I holding it wrong?

[Clint Wilson via dev-security-policy]

On Tuesday, April 9, 2019 at 12:08:16 PM UTC-6, Ryan Sleevi wrote:
> On Tue, Apr 9, 2019 at 11:25 AM Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Mozilla's wiki has a page about the subCAs
> >
> > https://wiki.mozilla.org/CA/Intermediate_Certificates
> >
> > On that page I see a link labelled:
> >
> > "Non-revoked, non-expired Intermediate CA Certificates chaining up to
> > roots in Mozilla's program with the Websites trust bit set"
> >
> > And clicking that link produces a CSV file. Fine so far.
> >
> > I anticipated that this CSV file would be a set of subCA certs which
> > were trusted by Firefox to issue leaf TLS certs, since on the face of
> > it that's what the title claims.
> >
> >
> > But, that seems to be wrong, for example the file includes
> > "Symantec Shared Individual Email Certificate Authority"
> > https://crt.sh/?id=197857126
> >
> > which as its name suggests does not have the Websites trust bit set
> 
> 
> > So. What's actually going on here? Is there a trick that I'm not
> > understanding to processing this file? Why are there certs in it that
> > actually aren't for trusted subCAs at all?
> >
> > Is the link wrong?
> >
> > What is the recommended procedure for someone who wants to determine
> > whether a random leaf cert they're looking at would in fact be trusted
> > in Firefox? Other than "try it in Firefox" ?
> >
> 
> I think it's merely a misparsing of the description.
> 
> The intermediate you referenced - https://crt.sh/?id=197857126 - chains to
> a "root in Mozilla's program with the Websites trust bit set". That root is
> https://crt.sh/?caid=1110, and you can see, it has the Website Trust Bit
> set.
> 
> I suspect you parsed it as "intermediates ... with the websites trust bit
> set", but that's not what that report is. The answer for how to determine
> that is, yes, to attempt to construct a chain and determine whether the
> intersection of the root trust policies (which are maintained in CCADB) and
> the attributes of all the certificates in all of the chains to that root
> overlap with the Website trust bit.
> 
> The answer for whether it would be trusted in Firefox is, indeed,
> canonically to "try it in Firefox". If you're willing to accept a more
> probabilistic approach (even if that actual probability may be 99.999%),
> then you'd need to evaluate the particular certificate paths. For example,
> you could use Golang along with the stock Go X.509 library (or if you want
> more nuanced handling and certificate path enumeration, ZMap's ZCrypto -
> https://github.com/zmap/zcrypto , as used by Censys) to do this. crt.sh
> uses PGSQL to compute these paths, if I recall correctly (
> https://github.com/crtsh/certwatch_db/blob/master/determine_ca_trust_purposes.fnc
> I
> believe)

Useful for ad-hoc chain-building or trust store inclusion checking, Mozilla 
also has "certsplainer" which can help establish whether a given cert is 
trusted in Firefox. Your example cert is here: 
https://tls-observatory.services.mozilla.com/static/certsplainer.html?id=186562432
 which will display the trust paths available for that certificate.
If you click into or upload a root, there's also a section explicitly 
identifying if it's trusted by Mozilla.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy