Hi,
Telia had a legacy use case to create smime certificates to enterprise RA for
some teams instead of a single persons. For that purpose it would be good to
omit subject:givenName and subject:surname and put group name to CN and still
use O value also. I suppose this is one use case for the
So I think the allowance is that an entity which operates a CA can use the its
Signing Service to generate the its Subscriber keys. Do we need to update the
definition? Or put is an note? Or leave as is?
We might be over-churning on this definition. What if a third party operates a
Signing
All,
I am looking for at least one more endorser for this ballot.
Thanks,
Ben
On Thu, Oct 12, 2023 at 4:23 PM Ben Wilson wrote:
> All,
>
> I am planning to introduce a Forum ballot to amend the Server Certificate
> Working Group Charter.
>
> At a high level, here are some of the proposed
I think these are good clarifications. I think it’s important to make sure the
definition of Signing Service accurately encompasses the cases where a
Subscriber is relying on the CA to provide key generation and protection, but
doesn’t accidentally pull anything inappropriate else into scope.
Hi Bruce,
I agree the current definition of Signing Service would encompass the CA’s own
Subscriber keys. However, we are proposing to amend the definition to:
“An organization other than the Subscriber or any of its Affiliates, that
generates the Key Pair and securely manages the Private
Hi Corey,
Can you please elaborate why you have the concern?
My first take is an example where a Signing Service must use FIPS 140-2 Level 3
and the Subscriber must use minimum Level 2. So if the Subscriber key was
generated by the Signing Service, then Level 3 would apply. I don’t see
In the case where the CA is generating its own Key Pairs to issue itself code
signing certificates, their obligations for key protection would be outlined in
the sections pertaining to Subscriber Key Pair protection, even if the Private
Key so happens to reside in a Signing Service that they
As a first idea, how about rewording that note in §7.1.4.2.5 the
following way?
“Legacy Generation profiles MAY omit the |subject:givenName|,
|subject:surname|, and |subject:pseudonym| attributes and include only
the |subject:commonName| as described in Section 7.1.4.2.2(a)
