On 19/4/2022 11:11 μ.μ., Ben Wilson wrote:
See responses below.
[...]
Although RFC 5280 does use "end entity certificate" (without the
hyphen), the current MRSP already uses "end-entity certificate" with
the hyphen, so changing it now would require that I replace it in
those other places as well. Should we add this as a GitHub issue to
resolve in a future version of the MRSP?
I don't have any strong feelings about this. I just noticed this subtle
difference and brought it to the community's attention. I thought of it
as similar to other proposed changes (SSL --> TLS, "CA operators",
subordinate --> intermediate, etc).
Section 6.1.1
- *cessationOfOperation*
/"the CA is made aware of any circumstance indicating that use of
a fully‐qualified domain name or IP address in the certificate is
no longer legally permitted (e.g. a court or arbitrator has
revoked a domain name registrant’s right to use the domain name, a
relevant licensing or services agreement between the domain name
registrant and the applicant has terminated, or the domain name
registrant has failed to renew the domain name)."/
This looks like a CA-driven revocationReason and seems to fit the
privilegeWithdrawn reason better.
This third bullet, quoted above, is very similar to the other two
bullets in this section for cessationofOperation ("the certificate
subscriber no longer controls, or is no longer authorized to use, all
of the domain names in the certificate;" "the certificate subscriber
will no longer be using the certificate because they are discontinuing
their website;"). Therefore, we think it fits here, too. A
subscriber can make the CA aware of such circumstances, and these
circumstances might not constitute a violation of the certificate
subscriber agreement (the intention of privilegeWithdrawn).
-*superseded
*
* /"//the CA obtains reasonable evidence that the validation of
domain authorization or control for any fully‐qualified domain
name or IP address in the certificate should not be relied
upon; or"/
* /"the CA has revoked the certificate for compliance reasons
such as the certificate does not comply with this policy, the
CA/Browser Forum's Baseline Requirements, or the CA’s CP or CPS."/
*
*Looking at these reasons, we have very similar intent for the
reason "privilegeWithdrawn". Most probably, the intent of the
revocationReason is to indicate /why/ a certificate has been
revoked. Relying Parties probably don't care if a new certificate
has been issued to replace a revoked one or not, but are more
interested on why a particular certificate was revoked.
What if we combine the second and third bullets (failure of domain/IP
address verification and compliance reasons) to read, "the CA has
revoked the certificate because it was not issued in full compliance
with this policy, the CA/Browser Forum's Baseline Requirements, or the
CA’s CP or CPS."? The reason being that we want "superseded" to
encompass certificate replacement situations where there has not been
a Subscriber's breach (privilegeWithdrawn).
I guess the term "breach" is a bit ambiguous because the current wording
in "privilegeWithdrawn" considers reasons like "the CA is made aware of
a material change in the information contained in the certificate" which
doesn't clearly indicate a Subscriber's breach.
If the intent is to add all related "subscriber-side violations/breach
of subscriber agreement/terms-of-use" reasons under
"privilegeWithdrawn", perhaps an opening paragraph describing this
intention -similar to the opening paragraph of
cessationOfOperation/affiliationChanged- is needed for
privilegeWithdrawn as well.
ITU-T X.509's description doesn't shed too much light either:
/"//*superseded*//indicates that the public-key certificate has
been superseded but there is no cause to suspect that the private
key has been compromised."/
We recommend adding these two bullets under the
"privilegeWithdrawn" reason so that CAs have a "preferred" reason
to indicate compliance, domain validation/authorization,
subscriber violation issues.
It seems that "privilegeWithdrawn" best fits the six bulleted items
already there.
See above. If the intent is to separate the revocation reasons between a
subscriber-side breach of the subscriber agreement/terms-of-use and a
CA-side violation/failure with "privilegeWithdrawn" and "superseded"
reasons respectively, then the bullet
* /"//the CA obtains reasonable evidence that the validation of domain
authorization or control for any fully‐qualified domain name or IP
address in the certificate should not be relied upon; or"/
means that there was something wrong with the CA
practices/implementation and validation information should not be relied
upon; nothing caused by the Subscriber. If that's the case, then it's
fine to remain under "superseded" as long as we clarify the intent a bit
more. I believe the implementation by CAs would be easier if they knew
that "privilegeWithdrawn" is targeted to subscriber-side violations and
"superseded" to CA-side violations, without being able to predict cases
which might fall under both :)
Dimitris.
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/bc8d7bd7-d0be-3e1c-0051-223a2f8714fd%40it.auth.gr.
