Tim -
I think that statement leaves out the next paragraph of RFC3647:
In a CP, it is possible to leave certain components, subcomponents, and/or
elements unspecified, and to stipulate that the required information will be
indicated in a policy qualifier, or the document to which a policy qualifier
points. Such CPs can be considered parameterized definitions. The set of
provisions should reference or define the required policy qualifier types and
should specify any applicable default values.
I think normally the policy qualifier points to a CPS, but it might be some
other document.
But in any case if both CP & CPS say "No stipulation" in regards to something
that Mozilla cares about like what validation methods are supported for TLS
certificates, then it is very hard to evaluate that set of "disclosed business
practices" to determine if the CA operates in accord with the BRs or Mozilla's
policy.
I think there may be some sections of a CP/CPS that are less critical, but in
terms of any section that is critical to the evaluation for inclusion in a
particular trust store, I would expect one of the 2 documents to clearly state
the operational practices of the CA rather than just stating "No Stipulation"
in both CP & CPS, unless the Policy Qualifier in issued certificates points to
some other document that contains that information.
Again - just my personal opinion.
wendy
Date: Tue, 9 Oct 2018 19:02:54 +0000
From: Tim Hollebeek
<tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>>
To:
"dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>"
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
Subject: RE: What does "No Stipulation" mean, and when is it OK to use
it in CP/CPS?
Message-ID:
<bn6pr14mb110664cd140c0a82f006afa483...@bn6pr14mb1106.namprd14.prod.outlook.com<mailto:bn6pr14mb110664cd140c0a82f006afa483...@bn6pr14mb1106.namprd14.prod.outlook.com>>
Content-Type: text/plain; charset="us-ascii"
RFC 3647 disagrees:
"Rather, a particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure."
" It is recommended that each and every component and subcomponent be
included in a CP or CPS, even if there is "no stipulation"; this will
indicate to the reader that a conscious decision was made to include
or exclude a provision concerning that topic. This drafting style
protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions."
-Tim
> -----Original Message-----
> From: dev-security-policy
> <dev-security-policy-boun...@lists.mozilla.org<mailto:dev-security-policy-boun...@lists.mozilla.org>>
> On Behalf Of Brown, Wendy (10421) via dev-security-policy
> Sent: Tuesday, October 9, 2018 2:55 PM
> To:
> dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
> Subject: RE: What does "No Stipulation" mean, and when is it OK to use
> it
in
> CP/CPS?
>
> Kathleen -
> My interpretation of a "No Stipulation" in a CP is that the Policy has
> "No
rules
> defined for this section"
> In these cases, I expect the CPS to state what is actually done in
> support
of
> that section and therefore "No Stipulation" is not appropriate in a CPS.
The
> CPS should instead state whether or not they implement anything in
response
> to that section or if they consider that section Not Applicable
> because
there
> are no stated requirements.
>
> It can mean slightly different things in different sections so for
> example
> 1.3.5 Other Participants - I would expect the CPS to list what other
> participants might be involved Where as
> 3.1.5 Uniqueness of Names - I would expect the CPS to state whether or
> not they enforce Uniqueness of names and if they do - how this is
> enforced In
a
> TLS CP/CPS that adheres to the BRs, I would expect the CPS to clearly
state
> which of the validation methods is supported and how, where the CP may
> leave this up to individual subordinate CAs by having No Stipulation
> at
the CP
> level. For these sections I would expect the CPS to either state the
method is
> not supported or it is and how. "Not applicable" would not be
appropriate.
>
> Thanks, (just my personal opinion)
>
> Wendy Brown
> Protiviti Government Services
> 703-299-4705 (office) 703-965-2990 (cell)
>
> wendy.br...@protiviti.com<mailto:wendy.br...@protiviti.com>
>
>
> -----------------------------
>
> Date: Tue, 9 Oct 2018 09:48:26 -0700
> From: Kathleen Wilson <kwil...@mozilla.com<mailto:kwil...@mozilla.com>>
> To:
> mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: What does "No Stipulation" mean, and when is it OK to use it
> in CP/CPS?
> Message-ID:
> <n5sdneed28pgrihgnz2dnuu7-fpnn...@mozilla.org<mailto:n5sdneed28pgrihgnz2dnuu7-fpnn...@mozilla.org>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> All,
>
> I would like to create some written rules about using "No Stipulation"
> in CP and CPS documents; e.g. what it means, and when it is OK to be used.
>
> First, I will appreciate your thoughts about what the term "No
Stipulation"
> means. e.g. does it mean one or all of the following?
> "No rules defined for this section"
> "This section is not applicable"
> "This section is not allowed"
> "This section is not used"
>
> Can "No Stipulation" mean different things based on the context of the
> section?
> For example
> "1.3.5 Other Participants
> No stipulation."
> Does that mean ?no other participants are allowed??
>
> Here is what RFC 3647 says about the term:
> ""
> While many topics are identified, it is not necessary for a CP or a
> CPS to include a concrete statement for every such topic. Rather, a
> particular CP or CPS may state "no stipulation" for a component,
> subcomponent, or element on which the particular CP or CPS imposes no
> requirements or makes no disclosure. In this sense, the list of
> topics can be considered a checklist of topics for consideration by
> the CP or CPS writer.
>
> It is recommended that each and every component and subcomponent be
> included in a CP or CPS, even if there is "no stipulation"; this will
> indicate to the reader that a conscious decision was made to include
> or exclude a provision concerning that topic. This drafting style
> protects against inadvertent omission of a topic, while facilitating
> comparison of different certificate policies or CPSs, e.g., when
> making policy mapping decisions.
> ""
>
> It seems a little ambiguous to me, so I would like to have a written
statement
> about what "No Stipulation" means within CP and CPS documents,
> especially in regards to SSL certificate issuance.
>
> Here are two examples that I've seen recently.
>
> == Example 1 ==
> In this situation, the CA has one CP that covers different types of
> roots,
so
> the CPS for the different roots has the details. There is no further
detailed
> public documentation beyond the CPS.
>
> In the CA's CP:
> 3.1.2 Need for Names to be Meaningful
> No Stipulation
> 3.1.5 Uniqueness of Names
> No Stipulation
> 3.2.2.1 Identity
> No Stipulation
> 3.2.2.2 DBA/Tradename
> No Stipulation
> 3.2.2.3 Verification of Country
> No Stipulation
> 3.2.2.4 Validation of Domain Authorization or Control No Stipulation
> 3.2.2.4.1 Validating the Applicant as a Domain Contact No Stipulation
> 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact No
> Stipulation
> 3.2.2.4.3 Phone Contact with Domain Contact No Stipulation
> 3.2.2.4.4 Constructed Email to Domain Contact No Stipulation
> 3.2.2.4.5 Domain Authorization Document No Stipulation
> 3.2.2.4.6 Agreed-Upon Change to Website No Stipulation
> 3.2.2.4.7 DNS Change
> No Stipulation
> 3.2.2.4.8 IP Address
> No Stipulation
> 3.2.2.4.9 Test Certificate
> No Stipulation
> 3.2.2.4.10 TLS Using a Random Number
> No Stipulation
> 3.2.2.4.11 Any Other Method
> This method has been retired and MUST NOT be used.
> 3.2.2.4.12 Validating Applicant as a Domain Contact No Stipulation
> 3.2.2.5 Authentication for an IP Address No Stipulation
> 3.2.2.6 Wildcard Domain Validation
> No Stipulation
> 3.2.2.7 Data Source Accuracy
> No Stipulation
> 3.2.2.8 CAA Records
> No Stipulation
> 3.2.3 Authentication of Individual Identity No Stipulation
> 3.2.4 Non-Verified Subscriber Information No Stipulation
> 4.7.4 Notification of New Certificate Issuance to Subscriber No
stipulation
> 4.9.7 CRL Issuance Frequency
> No Stipulation.
> 4.9.10 On-Line Revocation Checking Requirements No Stipulation
> 5.4.6 Audit Log Accumulation System (Internal vs. External) No
> Stipulation
> 6.1.5 Key Sizes
> No Stipulation
> 6.2.3 Private Key Escrow
> No Stipulation
> 6.2.5 Private Key Archival
> No Stipulation
> 6.2.6 Private Key Transfer into or from a Cryptographic Module No
> Stipulation
> 6.2.9 Deactivating Private Keys
> No Stipulation
> 6.3.2 Certificate Operational Periods and Key Pair Usage Periods No
> Stipulation
> 6.7 NETWORK SECURITY CONTROLS
> No stipulation
>
> The relevant CPS has the following sections with No Stipulation:
> 3.1.5 Uniqueness of Names
> No Stipulation
> 3.2.2.5 Authentication for an IP Address No Stipulation
> 3.2.2.6 Wildcard Domain Validation
> No Stipulation
> 4.7.4 Notification of New Certificate Issuance to Subscriber No
Stipulation
> 5.4.6 Audit Log Accumulation System (Internal vs. External) No
> Stipulation
> 6.2.3 Private Key Escrow
> No Stipulation
> 6.2.5 Private Key Archival
> No Stipulation
> 6.2.6 Private Key Transfer into or from a Cryptographic Module No
> Stipulation
> 6.2.9 Deactivating Private Keys
> No Stipulation
>
> In this example you can see that the CA clarifies in the CPS which
> domain validation methods can be used.
>
> I'm not sure how to interpret the sections listed above that have "No
> Stipulation" in both the CP and the CPS.
>
> For instance, when I see "3.2.2.5 Authentication for an IP Address"
> with
"No
> Stipulation" in the CPS, it is not clear to me if the CA does not
> allow
for IP
> Addresses to be included in SSL certs, or if the CA just allows any
> form
of
> verification of IP Addresses.
>
>
>
> == Example 2 ==
> In the following situation, the CA does not have a separate CP document.
> This one CPS document is the only public document about the CA's
> policies/practices.
>
> 1.3.5 Other Participants
> No stipulation.
> 3.2.2.4.1 Validating the Applicant as a Domain Contact No stipulation.
> 3.2.2.4.5 Domain Authorization Document No stipulation.
> 3.2.2.4.9 Test Certificate
> No stipulation
> 3.2.2.4.10 TLS Using a Random Number
> No stipulation
> 3.2.2.4.11 Any Other Method
> No stipulation
> 3.2.2.4.12 Validating Applicant as a Domain Contact No stipulation
> 3.2.4 Non-verified Subscriber Information No stipulation.
> 4.2.2 Approval or Rejection of Certificate Applications No stipulation.
> 4.4.1 Conduct Constituting Certificate Acceptance No stipulation.
> 4.4.2 Publication of the Certificate by the CA No stipulation.
> 4.5 Key Pair and Certificate Usage
> No stipulation.
> 4.5.1 Subscriber Private Key and Certificate Usage No stipulation.
> 4.5.2 Relying Party Public Key and Certificate Usage No stipulation.
> 4.7 Certificate Re-key
> No stipulation.
> 4.7.1 Circumstance for Certificate Re-key No stipulation.
> 4.7.2 Who May Request Certification of a New Public Key No stipulation.
> 4.7.3 Processing Certificate Re-keying Requests No stipulation.
> 4.7.4 Notification of New Certificate Issuance to Subscriber No
stipulation.
> 4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate No
> stipulation.
> 4.7.6 Publication of the Re-keyed Certificate by the CA No stipulation.
> 4.7.7 Notification of Certificate Issuance by the CA to Other Entities
> No stipulation.
> 4.9.8 Maximum Latency for CRLs
> No stipulation.
> 4.9.13 Circumstances for Suspension
> No stipulation.
> 4.9.14 Who Can Request Suspension
> No stipulation.
> 4.9.15 Procedure for Suspension Request No stipulation.
> 4.9.16 Limits on Suspension Period
> No stipulation.
> 4.12 Key Escrow and Recovery
> No stipulation.
> 4.12.1 Key Escrow and recovery Policy Practices No stipulation.
> 5.2.4 Roles Requiring Separation of Duties No stipulation.
> 5.4.4 Protection of Audit Log
> No stipulation.
> 5.4.5 Audit Log Backup Procedures
> No stipulation.
> 5.4.6 Audit Collection System
> No stipulation.
> 5.7.3 Entity Private Key Compromise Procedures No stipulation.
> 6.5.2 Computer Security Rating
> No stipulation.
> 7.1.5 Name Constraints
> No stipulation.
>
> In this situation, is it reasonable to assume that the domain
> validation procedures that have "No Stipulation" are not used? Or
> should the CA be required to use specific language to indicate that?
>
> Is it OK for the CA to say "No Stipulation" in all of the sections
> listed
above?
>
> What does "No Stipulation" mean in each of the sections listed above?
>
> ==
>
> As always, I will greatly appreciate your thoughtful and constructive
input on
> this discussion.
>
> Thanks,
> Kathleen
>
> NOTICE: Protiviti is a global consulting and internal audit firm
> composed
of
> experts specializing in risk and advisory services. Protiviti is not
licensed or
> registered as a public accounting firm and does not issue opinions on
> financial statements or offer attestation services. This electronic
> mail message is intended exclusively for the individual or entity to
> which it
is
> addressed. This message, together with any attachment, may contain
> confidential and privileged information. Any views, opinions or
conclusions
> expressed in this message are those of the individual sender and do
> not necessarily reflect the views of Protiviti Inc. or its affiliates.
> Any
unauthorized
> review, use, printing, copying, retention, disclosure or distribution
> is
strictly
> prohibited. If you have received this message in error, please
> immediately advise the sender by reply email message to the sender and
> delete all
copies
> of this message. Thank you.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists
> .mozilla.org%2Flistinfo%2Fdev-security-policy&data=02%7C01%7Cwendy
> .brown%40protiviti.com%7C2518987f0b924835824408d62e19dcbd%7C16532572d5
> 674d678727f12f7bb6aed3%7C0%7C0%7C636747085954626780&sdata=iM3pBoDE
> SB75MiyzJhEyuzuw3shlogQj%2Fq4wxyAsmqw%3D&reserved=0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL:
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.mozilla.org%2Fpipermail%2Fdev-security-policy%2Fattachments%2F20181009%2F2c4782c2%2Fattachment.p7s&data=02%7C01%7Cwendy.brown%40protiviti.com%7C2518987f0b924835824408d62e19dcbd%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C636747085954626780&sdata=WxC7SEJ6aUpieaID3g00IPkX%2F%2F0%2Bd5MnrcQH6SFrGxA%3D&reserved=0>
------------------------------
Subject: Digest Footer
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=02%7C01%7Cwendy.brown%40protiviti.com%7C2518987f0b924835824408d62e19dcbd%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C636747085954636788&sdata=7MCJTNmbjH%2BmrmbpzBqg7sTnF4lafZFamfPL2M5qV38%3D&reserved=0
------------------------------
End of dev-security-policy Digest, Vol 118, Issue 20
****************************************************
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
