RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Tim Hollebeek via dev-security-policy]

I think blank sections should be disallowed.  The entire purpose of "No 
stipulation" is to make it clear that the omission of content was intentional.

With regards to some of these sections being useful, I agree that a good CPS 
contains more than the minimum content required from the BRs.  I personally 
view the use of a "minimal CPS" (lightly modified version of the BRs) by some 
organizations as a cause for concern.  From the discussion at CABF Shanghai, it 
sounds like many people share my concern.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Joanna Fox via dev-security-policy
> Sent: Friday, October 19, 2018 1:39 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
> 
> On Thursday, October 18, 2018 at 5:47:14 PM UTC-7, Jakob Bohm wrote:
> > On 15/10/2018 20:01, Kathleen Wilson wrote:
> > > I have added the following section to the Required Practices wiki page:
> > >
> > >
> https://clicktime.symantec.com/a/1/7p3XgkAIErb9F2a7I0h79owDFBAc5ICeK
> > > jHbhT4MfRQ=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5
> > > faQ8DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_
> > >
> O0TIYHZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJk
> mVn4u
> > >
> HGorLgZriWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHr
> kv4ynQk
> > > rYfWuuUGTWbKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-
> YKf2C3IkEFjzQ1KM07-g
> > > 8GY5W2f-
> L8l3AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq
> > > -
> 0hOXZSjQMhd9U8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7Z
> FNQGGj8
> > >
> 9SqBMmPojMgjHEhA%3D%3D=https%3A%2F%2Fwiki.mozilla.org%2FCA%2
> FRequi
> > >
> red_or_Recommended_Practices%23BR_Commitment_to_Comply_statement
> _in_
> > > CP.2FCPS
> > >
> > > I will continue to appreciate feedback on this update.
> > >
> > > Thanks,
> > > Kathleen
> > >
> >
> > Upon closer look, it appears that most of the "No Stipulation" entries
> > in the BRs are things for which Mozilla would probably want explicit
> > statements, even though there are no specific BR requirements.
> >
> > For example:
> >
> > 1.5.1 Organization Administering this document (CP/CPS)
> > 1.5.3 Person Determining CPS suitability for the Policy
> > 1.5.4 CPS Approval procedures
> > 4.3.2 (Mostly relevant to customer relationship)
> > 4.4.1 (Only relevant to customer relationship)
> > 4.4.2 Publication of the certificate by the CA
> > 4.4.3 Notification of certificate issuance by the CA to other entities
> >(This would cover CT or other mechanisms suitable for CRLset
> > generation by Mozilla).
> > 4.5.2 Relying party public key and certificate usage
> >(This would typically cover disclaiming responsibility if users turn
> >off revocation checking or interpret the certificate as meaning
> >something other than a proof of identity of the private key holder).
> > 4.6 CERTIFICATE RENEWAL
> >This has been the subject of many discussions about appropriateness of
> >CA procedures.
> >   Except:
> > 4.6.4 (Mostly relevant to customer relationship)
> > 4.6.5 (Only relevant to customer relationship)
> > 4.7 CERTIFICATE RE-KEY
> >This has been the subject of many discussions about appropriateness of
> >CA procedures.
> >   Except:
> > 4.7.4 (Mostly relevant to customer relationship)
> > 4.7.5 (Only relevant to customer relationship)
> > 4.8 CERTIFICATE MODIFICATION
> >This has much relevance to situations of later discoveries of
> > discrepancies of changes in circumstances.  It is a recurring theme in
> > discussions about revoking such certificates.
> >   Except:
> > 4.8.4 (Mostly relevant to customer relationship)
> > 4.8.5 (Only relevant to customer relationship)
> > 4.9.4 Revocation Request Grace Period
> > 4.9.6 Revocation Checking Requirements for Relying Parties
> >This interacts closely with the features implemented in Mozilla products.
> > 4.9.8 Maximum Latency for CRLs
> > 4.10.3 Optional Features (for certificate status services)
> >This would for example indicate if the OCSP servers provide ways to
> > distinguish OCSP status for a real certificate and a fake certificate
> > with the same serial number.  If there are OCSP privacy features etc.
> > 4.11 (Mostly relevant to customer relationship)
> > 4.12 Key escrow and recovery policy and practices
> >This is the subject of a Mozilla requirement (not to provide such).
> >
> >
> >
> > Enjoy
> >
> > Jakob
> > --
> > Jakob Bohm, CIO, Partner, WiseMo A/S.
> >
> https://clicktime.symantec.com/a/1/qg1xJznChxmyUV0biuQ9q261sKYl0pswb3
> 9
> > gsDU-SoA=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5faQ8
> > DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_O0TIYH
> >
> ZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJkmVn4uH
> GorLgZr
> >
> iWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHrkv4ynQkr
> YfWuuUGTW
> > bKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-YKf2C3IkEFjzQ1KM07-
> 

Re: Identrust Commercial Root CA 1 EV Request

[Wayne Thayer via dev-security-policy]

I've filed a bug to track this misissuance and subsequent failure to
report: https://bugzilla.mozilla.org/show_bug.cgi?id=1500593

On Fri, Oct 19, 2018 at 6:22 AM identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via
> dev-security-policy wrote:
> > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> > > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via
> dev-security-policy wrote:
> > > > > 5.Explanation about how and why the mistakes were made, and not
> caught and
> > > > > fixed earlier.
> > > > >
> > > > > IdenTrust: The certificate was generated for a server within
> IdenTrust.
> > > > > The certificate contained internal domain names which were not
> reachable
> > > > > externally.  Two domain names in the SAN (
> Autodiscover.identrus.int and
> > > > > Mercury.identrus.int) were included at that time.  When the
> certificate
> > > > > was generated, these domains were internally hosted domains.
> > > >
> > > > This doesn't explain why the mistakes were made, nor does it explain
> why
> > > > they were not caught and fixed earlier.
> > >
> > > IdenTrust:IdenTrust has strict procedures regarding issuance of
> publicly
> > > trusted website certificates.  However at the time of this certificate
> > > issuance (2015) the procedures did allow ability to request exceptions
> for
> > > IdenTrust internal deployments that were not accessible externally.
> >
> > On what date was this exception-requesting element added to IdenTrust's
> > procedures?
> >
> > Please share the criteria which were used to evaluate exception requests.
> >
> > How many times has the procedure for requesting an exception been used?
> How
> > many times has the exception been granted?  I think it would be best if
> all
> > certificates issued under this exception process were made public, to
> ensure
> > that there is full transparency around the extent to which this exception
> > process was used.
> >
> > Finally, can you speak to why the BR requirements around internal names
> and
> > certificate expiry dates wasn't followed in this case?
> >
> > > However due to human error in implementation the server was made
> available
> > > external to our network.  Also due to human error, the IT staff failed
> to
> > > request certificate revocation when the certificate was no longer
> needed.
> >
> > Speaking of revocation, can you explain why this certificate wasn't
> caught
> > by the requirement to revoke all certificates containing internal names
> by
> > 2016-10-01?
> >
> > > Upon discovering of this misissuance on 02/22/2018, IdenTrust updated
> the
> > > website certificate approval procedures to eliminate the ability to
> > > request exceptions to the standard domain validation\verification
> > > procedures.  Please note that these website issuance procedures apply
> to
> > > all applications regardless of the TLD(s) requested in the certificate
> > > application.
> >
> > Correct me if I'm wrong, but does this mean that until the date you
> > specified above, it was procedurally possible for IdenTrust to issue a
> > certificate for *any* domain based on the invocation of this exception?
> > Under which subsection of BR section 3.2.2.4 does IdenTrust believe this
> > procedure was permitted as of the date of the procedure update?
> >
> > - Matt
> IdenTrust: We acknowledge the request for more information and are
> actively working on getting the necessary details to accurately respond.
>  We will respond as soon as we can.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Joanna Fox via dev-security-policy]

On Thursday, October 18, 2018 at 5:47:14 PM UTC-7, Jakob Bohm wrote:
> On 15/10/2018 20:01, Kathleen Wilson wrote:
> > I have added the following section to the Required Practices wiki page:
> > 
> > https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS
> > 
> > I will continue to appreciate feedback on this update.
> > 
> > Thanks,
> > Kathleen
> > 
> 
> Upon closer look, it appears that most of the "No Stipulation" entries
> in the BRs are things for which Mozilla would probably want explicit
> statements, even though there are no specific BR requirements.
> 
> For example:
> 
> 1.5.1 Organization Administering this document (CP/CPS)
> 1.5.3 Person Determining CPS suitability for the Policy
> 1.5.4 CPS Approval procedures
> 4.3.2 (Mostly relevant to customer relationship)
> 4.4.1 (Only relevant to customer relationship)
> 4.4.2 Publication of the certificate by the CA
> 4.4.3 Notification of certificate issuance by the CA to other entities
>(This would cover CT or other mechanisms suitable for CRLset 
> generation by Mozilla).
> 4.5.2 Relying party public key and certificate usage
>(This would typically cover disclaiming responsibility if users turn
>off revocation checking or interpret the certificate as meaning
>something other than a proof of identity of the private key holder).
> 4.6 CERTIFICATE RENEWAL
>This has been the subject of many discussions about appropriateness of
>CA procedures.
>   Except:
> 4.6.4 (Mostly relevant to customer relationship)
> 4.6.5 (Only relevant to customer relationship)
> 4.7 CERTIFICATE RE-KEY
>This has been the subject of many discussions about appropriateness of
>CA procedures.
>   Except:
> 4.7.4 (Mostly relevant to customer relationship)
> 4.7.5 (Only relevant to customer relationship)
> 4.8 CERTIFICATE MODIFICATION
>This has much relevance to situations of later discoveries of 
> discrepancies of changes in circumstances.  It is a recurring theme in
> discussions about revoking such certificates.
>   Except:
> 4.8.4 (Mostly relevant to customer relationship)
> 4.8.5 (Only relevant to customer relationship)
> 4.9.4 Revocation Request Grace Period
> 4.9.6 Revocation Checking Requirements for Relying Parties
>This interacts closely with the features implemented in Mozilla products.
> 4.9.8 Maximum Latency for CRLs
> 4.10.3 Optional Features (for certificate status services)
>This would for example indicate if the OCSP servers provide ways to 
> distinguish OCSP status for a real certificate and a fake certificate 
> with the same serial number.  If there are OCSP privacy features etc.
> 4.11 (Mostly relevant to customer relationship)
> 4.12 Key escrow and recovery policy and practices
>This is the subject of a Mozilla requirement (not to provide such).
> 
> 
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

The definition of blank could be integrated into the statement "The words "No 
Stipulation" mean that the particular document imposes no requirements related 
to that section."

It should be acceptable to leave items blank if they mirror the BR's.
Example: 3.2.4  Non-verified Subscriber Information 

Similarly, when the BR's state "No stipulation" and the CP or CPS corresponds 
to that same section in that same manner with the agreed definition of no 
requirements for that section.
Example: 4.2.3  Time to Process Certificate Applications 
No stipulation.

Thank you, Joanna
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Rob Stradling via dev-security-policy]

On 19/10/2018 10:42, Ben Laurie wrote:
> On Fri, 19 Oct 2018 at 10:38, Rob Stradling wrote:


FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever  
signed.>>>

Put it in Trillian? :-)


That had occurred to me.  ;-)

Would it be useful?


To be properly useful you would need to extend CRL protocols to include 
inclusion proofs, but its a step in the right direction. Is there a way 
to add ad-hoc stuff to CRLs?


Yes, CRLs have X.509v3 extensions, just like certificates do.

I suppose "CRL Transparency" would look much the same as CT, except that 
it would operate on X.509v3 CRL blobs instead of X.509v3 Certificate blobs.


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 19 Oct 2018 at 10:38, Rob Stradling  wrote:

> On 18/10/2018 22:55, Ben Laurie wrote:
> > On Fri, 12 Oct 2018 at 19:01, Rob Stradling wrote:
> >
> > On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
> >  > On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie  > > wrote:
> > 
> >  >> This is one of the reasons we also need revocation transparency.
> >  >
> >  > As tempting as the buzzword is, and as much as we love motherhood
> > and apple
> >  > pie and must constantly think of the children, slapping
> > transparency after
> >  > a word doesn't actually address the needs of the community or
> > users, nor
> >  > does it resolve the challenging policy issues that arise. Just
> > because
> >  > something is cryptographically verifiable does not mean it
> actually
> >  > resolves real world problems, or does not introduce additional
> ones.
> >  >
> >  > A simpler solution, for example, is to maintain an archive of
> > CRLs signed
> >  > by the CA. Which would address the need without the distraction,
> and
> >  > without having the technical equivalent of Fermat's Last Theorem
> > being
> >  > invoked. Let's not let the perfect (and unspecified) be the enemy
> > of the
> >  > good and reasonable.
> >
> > FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've
> ever
> > signed.
> >
> >
> > Put it in Trillian? :-)
>
> That had occurred to me.  ;-)
>
> Would it be useful?
>

To be properly useful you would need to extend CRL protocols to include
inclusion proofs, but its a step in the right direction. Is there a way to
add ad-hoc stuff to CRLs?


>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Rob Stradling via dev-security-policy]

On 18/10/2018 22:55, Ben Laurie wrote:

On Fri, 12 Oct 2018 at 19:01, Rob Stradling wrote:

On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
 > On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie mailto:b...@google.com>> wrote:

 >> This is one of the reasons we also need revocation transparency.
 >
 > As tempting as the buzzword is, and as much as we love motherhood
and apple
 > pie and must constantly think of the children, slapping
transparency after
 > a word doesn't actually address the needs of the community or
users, nor
 > does it resolve the challenging policy issues that arise. Just
because
 > something is cryptographically verifiable does not mean it actually
 > resolves real world problems, or does not introduce additional ones.
 >
 > A simpler solution, for example, is to maintain an archive of
CRLs signed
 > by the CA. Which would address the need without the distraction, and
 > without having the technical equivalent of Fermat's Last Theorem
being
 > invoked. Let's not let the perfect (and unspecified) be the enemy
of the
 > good and reasonable.

FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever
signed.


Put it in Trillian? :-)


That had occurred to me.  ;-)

Would it be useful?

--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy