Hi Pedro,
All CAs in the Apple Root Program are required to complete an audit based on
either WebTrust Principles and Criteria for Certification Authorities or ETSI
EN 319 411-1 LCP, NCP, or NCP+ per Section 1.1.1 of the ARP Policy. For
clientAuth-only CAs, these are currently the only audit cr
I also oversaw that…
Anyhow… @Clint, what are the audit requirements for these clientAuth CAs?
In your program you mention WTBR as a requirement for "TLS CAs”, but there’s no
distinction between clientAuth or serverAuth… while both are used to secure TLS
handshakes.
> On 17 May 2024, at 11:22,
On 16/5/2024 10:29 μ.μ., Clint Wilson wrote:
AFAIK Apple and Mozilla also don't have a specific "trust bit" for Client
Authentication. Only Microsoft does.
FWIW, Apple does indeed have a specific trust bit for id-kp-clientAuth EKU and
allows for (and ships) dedicated clientAuth Root CAs in t
On 16/5/2024 10:20 μ.μ., Clint Wilson wrote:
On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA)
wrote:
[...]
Regardless of the conclusion to the questions you posed, I’m failing
to see why we would want any other outcome than to have subCAs which
issue TBR-compliant TLS ce
> AFAIK Apple and Mozilla also don't have a specific "trust bit" for Client
> Authentication. Only Microsoft does.
FWIW, Apple does indeed have a specific trust bit for id-kp-clientAuth EKU and
allows for (and ships) dedicated clientAuth Root CAs in the Apple Root Program
(as outlined in 2.1.3
> On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA)
> wrote:
>
>
>
> On 15/5/2024 11:07 μ.μ., Clint Wilson wrote:
>> Hi Dimitris,
>>
>> I guess I’m confused about how this is relevant to the scope of the CA/BF as
>> it seems quite orthogonal to the questions you posed initially.
Hey Ryan,
Please note that I sent a correction saying that…
Where I said “you can’t propose clientAuth-only certs that work in Chrome”
I wanted to say “you can’t propose clientAuth-only certs that chain to Chrome
Store”
Now, about your question, I don’t think that there’s a use case where the
br
Hi Pedro,
Sharing our perspective below:
> I don’t know if you didn’t mention Chrome for a particular reason, but
actually that’s the Root program that makes me scratch my head while
reading these discussions… because AFAIK they only include Roots for TLS
serverAuth purposes, and not for clientAu
On 16/5/2024 3:21 μ.μ., Dimitris Zacharopoulos (HARICA) via
Servercert-wg wrote:
I don’t know if you didn’t mention Chrome for a particular reason,
No particular reason. It's just a relatively new Root Program compared
to others and I haven't bumped into a public tender that requires it :)
On 16/5/2024 12:20 μ.μ., Pedro FUENTES wrote:
Hello Dimitris,
I’m following closely this as I find very important.
About…
This is easy to answer. Some use cases need single-purpose client
authentication certificates. There are numerous use cases where
client authentication certificates are u
Sorry, small correction…
Where I said “you can’t propose clientAuth-only certs that work in Chrome”
I wanted to say “you can’t propose clientAuth-only certs that chain to Chrome
Store”
P
> On 16 May 2024, at 11:20, Pedro FUENTES via Servercert-wg
> wrote:
>
> Hello Dimitris,
> I’m following
Hello Dimitris,
I’m following closely this as I find very important.
About…
> This is easy to answer. Some use cases need single-purpose client
> authentication certificates. There are numerous use cases where client
> authentication certificates are used for strong authentication, I'm sure you
On 15/5/2024 11:07 μ.μ., Clint Wilson wrote:
Hi Dimitris,
I guess I’m confused about how this is relevant to the scope of the
CA/BF as it seems quite orthogonal to the questions you posed
initially. Regardless of how clients check certificates, the question
is about the issuance of a certif
Hi Dimitris,
I guess I’m confused about how this is relevant to the scope of the CA/BF as it
seems quite orthogonal to the questions you posed initially. Regardless of how
clients check certificates, the question is about the issuance of a certificate.
As a side-note, the question that comes to
On 15/5/2024 7:27 μ.μ., Clint Wilson wrote:
Apologies if I’m replying to the wrong thread, but I wanted to comment
on one point here.
On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos (HARICA) via
Servercert-wg wrote:
On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:
Apologies if I’m replying to the wrong thread, but I wanted to comment on one
point here.
> On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos (HARICA) via
> Servercert-wg wrote:
>
>
>
> On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:
>> I would agree to consider out-of-sco
On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:
I would agree to consider out-of-scope (of the BRs) a leaf certificate
with EKU=clientAuth issued by a SubCA that has EKU={server,client},
provided of course the leaf certificate does not assert a BR TLS
policy OID because thi
I would agree to consider out-of-scope (of the BRs) a leaf certificate
with EKU=clientAuth issued by a SubCA that has EKU={server,client},
provided of course the leaf certificate does not assert a BR TLS policy
OID because this would be contradictory.
Besides, at least one widely used linter c
18 matches
Mail list logo
