From sleevi at google.com  Mon Apr  5 22:51:24 2021
From: sleevi at google.com (Ryan Sleevi)
Date: Mon, 5 Apr 2021 18:51:24 -0400
Subject: [cabf_validation] Draft profiles work
In-Reply-To: <CACvaWvae5AgCon2UpFYK=LM97aVPLvKLKkFY+AXGPEH5TepTrw@mail.gmail.com>
References: <CACvaWvae5AgCon2UpFYK=LM97aVPLvKLKkFY+AXGPEH5TepTrw@mail.gmail.com>
Message-ID: <CACvaWvYF3zzv8a3B6GnGrBnRF=-WYm3tduM9jX6jApa7vNKGtg@mail.gmail.com>

Just a reminder on this that feedback on list or on GitHub is very welcome
(thanks Corey and Dimitris!)

I've updated based on all the feedback received so far, and would
definitely welcome substantive feedback on the requirements, as well as any
pet issues for style and format :)

On Tue, Mar 23, 2021 at 7:04 PM Ryan Sleevi <sleevi at google.com> wrote:

> While I'll be unable to make Thursday's call, I did want to share what I
> believe is a "mostly done" attempt to synthesize our profiles work into the
> BRs.
>
> You can access the diff at https://github.com/sleevi/cabforum-docs/pull/36
> (which shows the diff against SC41), and I've attached a rendered PDF
> version, which you can also access from the PR.
>
> There's obviously a lot of polish that can be done, and there are still
> areas that have outstanding questions to the list or need to be filled in,
> but I *think* enough of the thorny issues are sorted to give folks a chance
> to share their impressions.
>
> A random assortment of known issues/open questions:
>
>    - For fields which are SEQUENCEs of multiple structures (e.g. AIA, CRL
>    DP, certificatePolicies), what's the best way to communicate requirements?
>    I tried to find a good balance here, but curious folks takes. See Section
>    7.1.2.6.9 as an example of this.
>    - Lots of polish issues - feel free to add your own pet issue
>       - Still need to fix the page margins so that the page footer
>       doesn't run off the page (this also affects how the tables are laid out
>       whether on a new page or not)
>       - Should we left-align the tables or keep them centered?
>       - Should we add labels to every table?
>       - How to express informative text, like in 7.1.2.6.11 - is there a
>       better way to provide context?
>       - Still removing various bits of vestigial text (like 7.1.2.4 All
>       Certificates)
>       - How to express a good MUST/MAY requirement (e.g. see 7.1.6.3
>       around locality/stateOrProvince)
>       - Does having the footnote repeated on every page it's used help or
>       hurt, for common fields like non-critical nameConstraints.
>       - Weird table caption wrapping (see 7.1.2.2.3)
>       - The font size for the monospaced font appears to be slightly
>       larger than for our default font
>    - Various other weird bits
>       - e.g. for Subscriber certs, we allow the emailProtection EKU, but
>       the RFC 822 name SAN is prohibited, so are we effectively saying folks
>       should use the deprecated emailAddress subject attribute? Or should we just
>       make it clear that emailProtection+TLS == security disaster
>       - Separately discussed with DigiCert and Sectigo the handling for
>       'XX' certs, since they're the only ones using them. This approach may not
>       be final.
>    - Whether the certificate hierarchy makes sense, and if there are
>    other use cases missing
>       - For CAs, we have variance based on (Cross-cert vs not) x
>       (Affiliated with issuing CA vs not) x (TLS capable vs not) x (Technically
>       Constrained vs not)
>       - For Subscriber/Server certs, we have variance based on (level of
>       validation) x (country/state/locality information)
>    - I need to take another pass documenting all of the bits about the
>    MUST NOT / SHOULD NOT, which were derived from various intersections of our
>    existing requirements
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210405/69b4aba9/attachment.html>

From sleevi at google.com  Thu Apr 22 22:17:51 2021
From: sleevi at google.com (Ryan Sleevi)
Date: Thu, 22 Apr 2021 18:17:51 -0400
Subject: [cabf_validation] SRVNames in subjectAltNames and nameConstraints
Message-ID: <CACvaWvajpS82Lyu-_CeJYg=vyHYngOHepT263y7T0h46xHzrhw@mail.gmail.com>

As a follow-up to our call today, I filed
https://github.com/cabforum/servercert/issues/268 to capture the discussion
we had around SRVNames, so that we can explore steps going forward.

While it is not a priority of Google to add support for SRVNames, relative
to the other important work still to be done in the Forum, we're broadly
supportive of the goal.

Our proposed sequencing is this:

   1. A transition path so that existing technically constrained sub-CAs,
   which are not constrained by SRVNames, are phased out (e.g. revoked and
   replaced in time)
   2. Support for SRVNames added to browser clients. This cannot happen
   before 1, due to the security risk otherwise.
   3. Support for CAs issuing SRVNames
      - At a minimum, CAs MUST validate the Domain Portion in a manner
      consistent with validating a dNSName
      - It's unclear what policies should be developed for service names,
      particularly for those using the "host-based" demonstrations of control
      (e.g. 3.2.2.4.17/.18) - ALPN and .well-known. One path might be
mapping the
      port used for the validation to the IANA well-known port
registry (e.g. 80
      or 443 becomes "http" SRVName, 465/587 becomes "smtp", etc)

Since there was a desire to keep discussing, I said I'd file a GitHub issue
and discuss on list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210422/51233a5e/attachment.html>

From sleevi at google.com  Thu Apr 22 22:53:01 2021
From: sleevi at google.com (Ryan Sleevi)
Date: Thu, 22 Apr 2021 18:53:01 -0400
Subject: [cabf_validation] Backing Certificates
Message-ID: <CACvaWvaV4NWZwHDzAY+v4Q=m77aRxK2sLKr3o8MNj8d_pEmb=A@mail.gmail.com>

Per our call today, I filed
https://github.com/cabforum/servercert/issues/266 to track the discussion
had around backdating certificates, both subscriber certs and CA
certificates.

Given that the concerns of backdating equally tie in to the validation of
information, it seemed useful to have the discussion within the
subcommittee to see if there's alignment on a path forward for
reducing/prohibiting backdating.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210422/6ab44d6e/attachment.html>

From dxhood at godaddy.com  Fri Apr 23 16:18:42 2021
From: dxhood at godaddy.com (Daniela Hood)
Date: Fri, 23 Apr 2021 16:18:42 +0000
Subject: [cabf_validation] Leaving GoDaddy
Message-ID: <SA0PR02MB72600490C252E6B5A2A6A996D1459@SA0PR02MB7260.namprd02.prod.outlook.com>

Hello all,

I am just writing to let you all know that today is my last day with GoDaddy as I am moving into a new professional challenge.

I would like to thank all of you for the work and collaboration these past years here in the forum.

It has been a pleasure working with all of you!

Kind Regards,

Daniela Hood


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210423/20833c9b/attachment.html>

From aaron at letsencrypt.org  Mon Apr 26 19:05:32 2021
From: aaron at letsencrypt.org (Aaron Gable)
Date: Mon, 26 Apr 2021 12:05:32 -0700
Subject: [cabf_validation] Backing Certificates
In-Reply-To: <01000178fbc9fb76-6e4ed36b-baa9-43bd-8aa6-70dc3dd814e3-000000@email.amazonses.com>
References: <01000178fbc9fb76-6e4ed36b-baa9-43bd-8aa6-70dc3dd814e3-000000@email.amazonses.com>
Message-ID: <CAEmnEreUhCRamdaxmA8j9j9j03b=VH4DAL+=K55gtC_OypPTcQ@mail.gmail.com>

Merely as a data point, Let's Encrypt / ISRG's ACME implementation
(Boulder) does not allow any forward-dating[1]. We do backdate all of our
certificates[2] a small amount (1 hour) to provide leeway for clock skew,
and separately enforce that certificates are not backdated[3] by more than
a small amount (1 hour 5 minutes).

Speaking personally: since we do allow validation re-use (for up to 398
days, as of SC42v2), it would make sense to also explicitly limit
backdating to the period in which the CA had validated the certificate
data. Because a given certificate (particularly OV or EV) may contain
multiple pieces of data which were validated at different times, the
backdating must be restricted to the period of time when *all* certificate
data was validated, not the earliest validation. And then there should be a
small (on the order of hours) grace period to account for clock skew. I
would propose something like:

Section 4.2.2, or Section 4.3.1:
CAs SHALL NOT issue Subscriber Certificates containing `notBefore` dates
earlier than 24 hours prior to the most recent time at which certificate
data was validated as per Section 3.2.

This has a few falings: I'm honestly not sure which section it better fits;
the phrasing is awkward; and it doesn't address the scenario of "I perform
this same validation every 30 days and it's always been valid for the past
year; how far back can I backdate?".

Aaron

[1]
https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/issuance/issuance.go#L328-L330
[2]
https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/ca/ca.go#L479
[3]
https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/issuance/issuance.go#L325-L327

On Thu, Apr 22, 2021 at 3:53 PM Ryan Sleevi via Validation <
validation at cabforum.org> wrote:

> Per our call today, I filed
> https://github.com/cabforum/servercert/issues/266 to track the discussion
> had around backdating certificates, both subscriber certs and CA
> certificates.
>
> Given that the concerns of backdating equally tie in to the validation of
> information, it seemed useful to have the discussion within the
> subcommittee to see if there's alignment on a path forward for
> reducing/prohibiting backdating.
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210426/f252aec2/attachment.html>

From sleevi at google.com  Mon Apr 26 19:22:51 2021
From: sleevi at google.com (Ryan Sleevi)
Date: Mon, 26 Apr 2021 15:22:51 -0400
Subject: [cabf_validation] Backing Certificates
In-Reply-To: <CAEmnEreUhCRamdaxmA8j9j9j03b=VH4DAL+=K55gtC_OypPTcQ@mail.gmail.com>
References: <01000178fbc9fb76-6e4ed36b-baa9-43bd-8aa6-70dc3dd814e3-000000@email.amazonses.com>
 <CAEmnEreUhCRamdaxmA8j9j9j03b=VH4DAL+=K55gtC_OypPTcQ@mail.gmail.com>
Message-ID: <CACvaWvap3PwhcypW9H5oTf06uxsDxHQZSr1SAz9h_7W=dbKb+w@mail.gmail.com>

On Mon, Apr 26, 2021 at 3:05 PM Aaron Gable <aaron at letsencrypt.org> wrote:

> Speaking personally: since we do allow validation re-use (for up to 398
> days, as of SC42v2), it would make sense to also explicitly limit
> backdating to the period in which the CA had validated the certificate
> data. Because a given certificate (particularly OV or EV) may contain
> multiple pieces of data which were validated at different times, the
> backdating must be restricted to the period of time when *all* certificate
> data was validated, not the earliest validation. And then there should be a
> small (on the order of hours) grace period to account for clock skew. I
> would propose something like:
>
> Section 4.2.2, or Section 4.3.1:
> CAs SHALL NOT issue Subscriber Certificates containing `notBefore` dates
> earlier than 24 hours prior to the most recent time at which certificate
> data was validated as per Section 3.2.
>
> This has a few falings: I'm honestly not sure which section it better
> fits; the phrasing is awkward; and it doesn't address the scenario of "I
> perform this same validation every 30 days and it's always been valid for
> the past year; how far back can I backdate?".
>

If I'm understanding correctly, this would allow backdating for up to a
year. That seems significantly longer than either desirable or necessary,
but it wasn't clear if that was intentional, and if so, if it was merely a
consistency argument or if there was a further use case beyond clock skew?

If I'm also understanding correctly, it would allow backdating if you stay
with your current CA, but disallow backdating if you change CAs. From the
EVGs, we know that this significantly disadvantages end users, by making it
harder to change CAs, whether for business reasons (e.g. a better deal) or
in response to CA incidents (e.g. CA X keeps screwing up validation leading
to revocation, or CA Y is being phased out from root programs due to
issues).

To that end, it's also unclear how relevant the "clock skew" issue is, and
so data like this from ISRG is super-useful in figuring out what's a
"reasonable" threshold. To be honest, 30 days felt unreasonably long, 7
days as well, and so something like an hour or two feels... closer to
reasonable, if it's allowed at all? To some extent, clock skew can/should
be viewed as an RP problem (i.e. similar to nameConstraints), and unless
it's particularly wide-spread or egregious (i.e. with data to support the
claim), it seems like even any allowance should be carefully reasoned about.

There are concrete issues with backdating, such as how RPs and Root
Programs can verify whether or not a given CA was in compliance with the
requirements, both for certificates issued "newer" (and thus subject to
more requirements) and for distinguishing certificates issued after
requirements have been lessened (and appropriately backdated) vs those that
were inappropriately issued during a time of more rigid requirements
(contemporaneously misissued).

Obviously, intermediates are more complex, due to the intersection of some
clients wanting to use "greatest overall validity period", others wanting
to use "newest notBefore", and still others wanting to use "latest
notAfter". Yet those three requirements combined suggest that there's still
a potential at a backdating-less future: if an intermediate has validity
0...10, you can satisfy each of those constraints with validity 5...16 when
issuing a new version at T=5, rather than backdating to 1..12. The only
distinction I'm aware of is around how long Issuing CAs wish to allow
third-party sub-CAs to operate (e.g. the contract period, when using 3P
Sub-CAs), and I'm not sure how important that is.

I mention all of this because while the Issue looks to sort of capture what
a "minimum" backdating policy is (for profiles v1), I don't want it to be
thought of backdating as indefinitely allowable (e.g. it should be fixed
for profiles v2). I think the profiles work needs to say *something *about
the validity periods, so tried to pick an initial "not too different from
observed status quo" today, while hopefully sparking discussion like this
about what the end state should be, if it's allowed at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210426/f8316c98/attachment.html>

From aaron at letsencrypt.org  Mon Apr 26 19:58:02 2021
From: aaron at letsencrypt.org (Aaron Gable)
Date: Mon, 26 Apr 2021 12:58:02 -0700
Subject: [cabf_validation] Backing Certificates
In-Reply-To: <CACvaWvap3PwhcypW9H5oTf06uxsDxHQZSr1SAz9h_7W=dbKb+w@mail.gmail.com>
References: <01000178fbc9fb76-6e4ed36b-baa9-43bd-8aa6-70dc3dd814e3-000000@email.amazonses.com>
 <CAEmnEreUhCRamdaxmA8j9j9j03b=VH4DAL+=K55gtC_OypPTcQ@mail.gmail.com>
 <CACvaWvap3PwhcypW9H5oTf06uxsDxHQZSr1SAz9h_7W=dbKb+w@mail.gmail.com>
Message-ID: <CAEmnErdSS9h=zY+QY8KtrWSHVtMP3na3LJjQYBJZgaWsTPh8_Q@mail.gmail.com>

On Mon, Apr 26, 2021 at 12:23 PM Ryan Sleevi <sleevi at google.com> wrote:

> If I'm understanding correctly, this would allow backdating for up to a
> year. That seems significantly longer than either desirable or necessary,
> but it wasn't clear if that was intentional, and if so, if it was merely a
> consistency argument or if there was a further use case beyond clock skew?
>

Yep, precisely, this is solely an argument from consistency. I too
*believe* that backdating can/should be restricted to a much
shorter timeframe than ~398 days, but I personally have little to no
experience/grounds with which to make that argument.


> If I'm also understanding correctly, it would allow backdating if you stay
> with your current CA, but disallow backdating if you change CAs. From the
> EVGs, we know that this significantly disadvantages end users, by making it
> harder to change CAs, whether for business reasons (e.g. a better deal) or
> in response to CA incidents (e.g. CA X keeps screwing up validation leading
> to revocation, or CA Y is being phased out from root programs due to
> issues).
>

Oh, this is a very interesting point that hadn't occurred to me. Yes, if an
end-user wants or needs a larger backdate for some reason, then yes that
would provide some measure of CA lock-in. This is obviously reduced in
proportion to the maximum allowable backdate, with something on the order
of hours providing essentially no incentive to stay with a CA that already
has your validation cached.


> To that end, it's also unclear how relevant the "clock skew" issue is, and
> so data like this from ISRG is super-useful in figuring out what's a
> "reasonable" threshold. To be honest, 30 days felt unreasonably long, 7
> days as well, and so something like an hour or two feels... closer to
> reasonable, if it's allowed at all? To some extent, clock skew can/should
> be viewed as an RP problem (i.e. similar to nameConstraints), and unless
> it's particularly wide-spread or egregious (i.e. with data to support the
> claim), it seems like even any allowance should be carefully reasoned about.
>

We unfortunately have no way to tell if our 1-hour clock skew mitigation is
"sufficient". If there are subscribers who are unable to use our
certificates immediately after issuance due to a clock skew greater than
one hour, we have no way to detect that failure mode. But to the best of my
knowledge we have also never received any complaints about a certificate
being unusable due to its notBefore date.

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210426/94590bec/attachment-0001.html>

From sleevi at google.com  Mon Apr 26 20:13:14 2021
From: sleevi at google.com (Ryan Sleevi)
Date: Mon, 26 Apr 2021 16:13:14 -0400
Subject: [cabf_validation] Backing Certificates
In-Reply-To: <CAEmnErdSS9h=zY+QY8KtrWSHVtMP3na3LJjQYBJZgaWsTPh8_Q@mail.gmail.com>
References: <01000178fbc9fb76-6e4ed36b-baa9-43bd-8aa6-70dc3dd814e3-000000@email.amazonses.com>
 <CAEmnEreUhCRamdaxmA8j9j9j03b=VH4DAL+=K55gtC_OypPTcQ@mail.gmail.com>
 <CACvaWvap3PwhcypW9H5oTf06uxsDxHQZSr1SAz9h_7W=dbKb+w@mail.gmail.com>
 <CAEmnErdSS9h=zY+QY8KtrWSHVtMP3na3LJjQYBJZgaWsTPh8_Q@mail.gmail.com>
Message-ID: <CACvaWvZ4PNPgL+akyEhuqPPyYL7Q=mgZoC+ZXTGCDdO6z7gp9Q@mail.gmail.com>

On Mon, Apr 26, 2021 at 3:58 PM Aaron Gable <aaron at letsencrypt.org> wrote:

> To that end, it's also unclear how relevant the "clock skew" issue is, and
>> so data like this from ISRG is super-useful in figuring out what's a
>> "reasonable" threshold. To be honest, 30 days felt unreasonably long, 7
>> days as well, and so something like an hour or two feels... closer to
>> reasonable, if it's allowed at all? To some extent, clock skew can/should
>> be viewed as an RP problem (i.e. similar to nameConstraints), and unless
>> it's particularly wide-spread or egregious (i.e. with data to support the
>> claim), it seems like even any allowance should be carefully reasoned about.
>>
>
> We unfortunately have no way to tell if our 1-hour clock skew mitigation
> is "sufficient". If there are subscribers who are unable to use our
> certificates immediately after issuance due to a clock skew greater than
> one hour, we have no way to detect that failure mode. But to the best of my
> knowledge we have also never received any complaints about a certificate
> being unusable due to its notBefore date.
>

Yeah, I'm aware of the work Google did in the space previously -
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/04822a2487f3cd27ff92dbfddf42d947acdc4257.pdf
- but that explicitly excluded samples of < 24 hour of skew, and also only
looked at users who encountered TLS errors (and thus not an overall
percentage).

TLS Delegated Credentials
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10#section-3>
(deployed by Facebook
<https://engineering.fb.com/2019/11/01/security/delegated-credentials/> and
Cloudflare <https://blog.cloudflare.com/keyless-delegation/>, as well as
Mozilla
<https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/>)
uses a validity period of just 7 days for the Delegated Credentials, with
an explicit acknowledgement
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10#section-5.1>
that clock skew is an operational risk, but I haven't heard of
significant operational issues with it (although I haven't been following
closely), so it's very likely that "less than 7 days" is entirely
reasonable.

My assumption for CAs is going to be data based on support queries and
support load, which hopefully they can provide in concrete terms (e.g. x%
of support cases for Y million certs) rather than relative (i.e. "we hear
some users have issues"). But this also ties back into v1 and v2 for
profiles: it could be that the entirely reasonable end goal (absent
evidence) is to eliminate backdating, and a v1 "common sense" profile gives
CAs enough breathing room to incrementally improve their profile and gather
that data. For example, an ideal outcome would be "We started with X days,
then moved to Y days (where Y < X). We saw a Z% increase in support tickets
initially, but after N days, those subsided", which gives operational
experience data to help drive the discussion about whether X, Y, or 0 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210426/7afd89ba/attachment.html>

From bwilson at mozilla.com  Tue Apr 27 17:28:56 2021
From: bwilson at mozilla.com (Ben Wilson)
Date: Tue, 27 Apr 2021 11:28:56 -0600
Subject: [cabf_validation] Meeting Minutes for Subcommittee Teleconference -
	2021-Apr-22
Message-ID: <CA+1gtaZ89bGRZhmbmMKemEdpybtguEb29SDjei7kXpbtudP9FQ@mail.gmail.com>

Here are the draft minutes.

*Validation Subcommittee Meeting April 22, 2021*

*Antitrust statement*: Read by Tim

*Attendees*:  Ben Wilson, Andrea Holland, Clint Wilson, Aneta Wojtczak, Tim
Hollebeek, Corey Bonnell, Bruce Morton, Curt Spann, Enrico Entschew, Doug
Beattie, I?igo Barreira, Janet Hines, Johnny Reading, Ryan Sleevi, Michelle
Coon, Niko Carpenter, Paul van Brouwershaven, and Wayne Thayer

*Agenda:* Wildcards, CAA and Certificate Profile Updates

*Wildcards & ADNs (SC45):* Ryan worked with Dimitris re: how work relates
to appendix B (.onion validation rules) and whether a host-based control
actually demonstrates control over the whole domain name space.

Sites that use .onion certificates have a Tor daemon on one server that is
doing proxying for different subdomains.  Subdomains don?t go over the Tor
network, they are conveyed by the host header if you?re using http. The
daemon runs on one server and inspects the SNI to dispatch to other servers.

Control over one of these destination servers doesn?t mean you have control
over the onion private key or the entire domain namespace. Control over the
destination server doesn?t mean you control the proxy server.  Purpose of
the ballot is to make it clear that the validation of a subdomain is not
validation of the domain namespace or of subdomains beneath it.

The implementation requirement date is being moved from October 2021 to
December 2021.

Corey ? ACME IP address validation discussion at IETF is making some
security assumptions ? concerns about passive proxying and whether use of
SNI is sufficient demonstration of control.

Ryan ? for this ballot, we are not making such assumptions - control over
private key doesn?t assume authorization for the namespace.  The primary
method for demonstrating control would be the CSR method using the private
key.  The well-known URI cannot be used to demonstrate control of the whole
namespace.

*CAA ballot (SC46):* Purpose of the ballot is to remove DNS operator
exception from the CAA-checking requirements. You always check CAA. That
ballot is ready to go.

*Certificate Profiles*: Ryan announced items to resolve or to call out or
to pay attention to.
*Name Constraints and BR section 7.1.2.4.2:*  PDFs circulated on the list,
there is dif file you can look at ?
https://github.com/sleevi/cabforum-docs/pull/36/files

BRs talk about the three constraints ? DNS constraints, IP address
constraints, and Directory Name constraints.  The idea is to transition
SHOULD NOTs (profiles phase 1) to MUST NOTs (profiles phase 2). In Mozilla
policy, it doesn?t address *RFC 822 and SRV names*. You could be exempt
from audits, but still subject to Mozilla?s policy and CCADB disclosure
would be required. The proposed profile would illustrate how to handle
constraints for RFC 822 and SRV names. Under Mozilla Policy, the domain
part of the RFC822 name must be validated per BR ? 3.2.2.4. For SRV names,
the name portion must be validated. The goal is to provide guidance for CAs
trying to technically constrain intermediate CAs.

If SRV names were supported in browsers, all of these SRV names would not
be technically supported and it would create a security risk. Clients can
introduce support for the new name types, but the security gap needs to be
closed first.  There needs to be a transition as CAs issue newer
intermediate CAs. Clients/browsers won?t support SRV until CAs have
technically constrained their intermediate CAs by SRV names. Ryan will
create an issue in the servercert GitHub repository to track steps and
conclusions.

With regard to *non-critical name constraints*, Ryan had a question for
Apple.  In the profiles v.1 phase, it was decided to go with non-critical
name constraints because of Apple and OpenSSL098. What about a 2022 sunset
for non-critical name constraints (requiring that they be marked critical)?
This would apply to any new sub CAs.  Dimitris noted that there are relying
parties still using old mobile phones that we need to look at.  For
example, it is hard to get relying party data because they are customers of
customers (e.g. Bank Customers).  Ryan noted that there are these issues
and he?ll file an issue in the GitHub repository and kick off a discussion
on the validation list.

*Cross certificates*. Ryan noted that in the profiles he was trying to
clarify when you issue a cross-certificate to a sub CA. Now it will be
called a cross-certified subordinate CA certificate. See BR ? 7.1.2.6.

Another related issue is that today we don?t consistently use ?subscriber
certificates? and ?server certificates?.  In section 7.1.2.6, the word
?server? is added in parenthesis ? (Server) ? to clarify that is the end
entity certificate profile because there is a language issue in the BRs
today.

Ryan asked whether his current approach in sections 7.1.2.6.1 ? 7.1.2.6.5
(IV, DV, OV, EV) was acceptable.  Then, there are two other types of end
entity certificates (not to be tackled in the profiles v1 phase) ? *(a)
signed-exchange certificates* with extensions and issues with EKU
compatibility and they are 90-day certificates.  Intent is that they
authenticate the domain name just like TLS certificates and they want to be
treated like TLS certificates, and *(b) delegated credential certificates*
? that are server certificates that indicate the server supports delegated
credentials by protecting keys used in Cloudflare and Facebook, and Mozilla
has been supporting these. Neither of these have been finalized yet in IETF
(but they need references and runnable code).

Ryan has also updated the pull request description for WIP pull request #36
to explain why things are changing. The next step is to move this to a CABF
pull request.

*Validity Periods*

These are TBD in every certificate profile.  There has been concern about
backdating (pre-dating, too) server certificates. E.g. strawman proposal is
to prohibit back dating past 30 days and only if the information was valid
at that time. Thus, you would be prohibited from back dating a server
certificate if you verified the domain only today. Also, there would be no
pre-dating ? you cannot issue a certificate in the future.

Tim ? last time we talked about this, we were not going to allow backdating
more than 7 days, but there was still debate about that because there was
still an unresolved clock-skew issue.  We couldn?t get consistent
information. One issue, for example, is that customers want their
certificates as quickly as possible, so certificates are issued as soon as
validation is performed.  So the second part of the requirement (only if
the information was validated), presents a problem because the reason
for  backdating
is to account for clock skew.

Ryan ? what is the right balance?

Tim ? We need two rules- one for short backdating and one for long
backdating.

I?igo ? what about CAs trying to avoid requirements?

Ryan ? yes, we need to make sure that the BR addresses this, and validity
periods would still need to be observed.

*Backdating CAs* ? the effect on optimal path-building necessitates some
degree of backdating. The rules for CAs needs to be more permissive, but
with a caveat. Let?s say you have an existing CA with a given SPKI, and you
are trying to replace it.  If you are transitioning to a new certificate
from an existing certificate, backdating is fine.

Curt: Does there need to be a tie to the audit window?

Ryan: Look at section 7.1.2.2.1 of the document. I think your question
relates to the replacement of a CA with a cross certificate. Thus, if the
certificate was audited according to the then-existing requirements, and
everything was good, then you can still backdate. In other words, if you
have all of the audits, then you can backdate to that period. But if you
created the root or sub CA and it was not audited for a period of time,
then you cannot backdate.

Adjourned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210427/82db0acb/attachment.html>