Re: SHA-1 S/MIME certificates

[Andrew R. Whalley]

On Wed, Mar 30, 2016 at 2:23 PM, Kathleen Wilson 
wrote:

> On 3/30/16 1:53 PM, Jeremy Rowley wrote:
>
>> I think a required move away from SHA1 client certs requires a bit more
>> planning.
>>
>> 1) There hasn't been a formal deprecation of all SHA-1 certificates in
>> any root store policy. There has been a formal deprecation by the CAB Forum
>> of SHA1 server certificates. Considering many of the client cert issuance
>> is governed by various national schemes (FBCA in the US and the Qualified
>> Cert program in the EU), care is necessary in enacting policies that impact
>> the use of client certificates. Although I recognize the need for Mozilla
>> to ensure a safe onine experience for all its users, I'm sure they don't
>> want to undermine entire trust frameworks built on these certificates.
>> (Yes, I know FBCA requires SHA2 now).
>>
>> 2) The browsers are already deploying code to reject SHA1 certificates
>> encountered. If this is true, what is the harm in continued SHA1 client
>> certificate issuance until the national schemes have all updated their
>> requirements? Mozilla is protected but the national bodies (and financial
>> institutions) can continue using their software for client authentication.
>> I do think we should move to SHA2, but I don't think the prior notice has
>> occurred with respect to SHA1 client certs.
>>
>> 3) Because Mozilla doesn't have a policy against reissuance of SHA1
>> intermediates for client certificates, I don't think your suggestion to
>> only permit reissuance of limited SHA1 intermediates is feasible. I do
>> think requiring a constraint against general SHA1 intermediates (that lack
>> technical restrictions to prevent server certs) is a good idea to ensure
>> the intermediates are only used for s/MIME or code signing.
>>
>> 4) Documenting why outdated algorithms/key sizes/anything else are used
>> always ends up being "For support of legacy devices". I don't see much
>> value in that. It becomes an exercise in creating an automatic label
>> applied to each certificate.
>>
>> In all, I think clientAuth certs are different than serverAuth certs. CAs
>> issuing clientAuth certs wouldn't necessarily be aware of the intent to
>> deprecate.  I also do not think Mozilla has as large of stake in client
>> certificates as it does server certs. Therefore, any plan to move away from
>> SHA1 client certs should start with:
>> A) An announcement that client certs will be deprecated
>> B) A question to the public about what software is still requiring the
>> use of SHA1 certs and the impact of requiring SHA2 certs, and
>> C) A date when SHA1 client certs will be deprecated
>>
>> Again, I'm not opposed to moving to SHA2 client certs, but I don't think
>> Mozilla has conveyed to the public its intent to do so.
>>
>>
>>
>
> I think Jeremy is correct, that Mozilla's previous communications about
> SHA-1 certs was only in regards to TLS/SSL certs.
>
> Would anyone object to me changing Actions 1a and 1b to the following?
>

Looks reasonable to me.


> (note, using date 2016-04-01 for the CAs who don't have the Websites trust
> bit enabled will make it so we can easily filter out those responses)
> ~~
> ACTION #1a: As previously communicated, CAs should no longer be issuing
> SHA-1 certificates chaining up to root certificates included in Mozilla's
> CA Certificate Program. This includes TLS/SSL certificates, as well as any
> intermediate certificates that they chain up to. Check your systems and
> those of your subordinate CAs to ensure that SHA-1 based TLS/SSL
> certificates chaining up to your included root certificates are no longer
> being issued, and that any such certificates issued after 2016-01-01 have
> been revoked. Please enter the last date that a SHA-1 based TLS/SSL
> certificate was issued that chained up to your root certificates included
> in Mozilla's program. If your included root certificates do not have the
> Websites trust bit enabled, then please enter 2016-04-01. (Required)
>
>
> ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL
> certificates that chain up to your root certificates included in Mozilla's
> CA Certificate Program will either expire or be revoked. If your included
> root certificates do not have the Websites trust bit enabled, then enter
> 2016-04-01.
>
> As previously communicated we plan to show the “Untrusted Connection”
> error whenever a SHA-1 certificate is encountered in Firefox after January
> 1, 2017.
>
> We recommend that you put safeguards into place that will prevent the
> future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1
> based intermediate certificates that chain up to your root certificates
> included in Mozilla's CA Certificate Program. (Required)
>
> ~~
>
>
> I think we can keep Action 1c as-is, because option (d) should capture
> information about issuance of S/MIME certs.
>
>
> Thanks,
> Kathleen
>
>
>
> ___
> 

Re: SHA-1 S/MIME certificates

[Kathleen Wilson]

On 3/30/16 1:53 PM, Jeremy Rowley wrote:

I think a required move away from SHA1 client certs requires a bit more 
planning.

1) There hasn't been a formal deprecation of all SHA-1 certificates in any root 
store policy. There has been a formal deprecation by the CAB Forum of SHA1 
server certificates. Considering many of the client cert issuance is governed 
by various national schemes (FBCA in the US and the Qualified Cert program in 
the EU), care is necessary in enacting policies that impact the use of client 
certificates. Although I recognize the need for Mozilla to ensure a safe onine 
experience for all its users, I'm sure they don't want to undermine entire 
trust frameworks built on these certificates. (Yes, I know FBCA requires SHA2 
now).

2) The browsers are already deploying code to reject SHA1 certificates 
encountered. If this is true, what is the harm in continued SHA1 client 
certificate issuance until the national schemes have all updated their 
requirements? Mozilla is protected but the national bodies (and financial 
institutions) can continue using their software for client authentication. I do 
think we should move to SHA2, but I don't think the prior notice has occurred 
with respect to SHA1 client certs.

3) Because Mozilla doesn't have a policy against reissuance of SHA1 
intermediates for client certificates, I don't think your suggestion to only 
permit reissuance of limited SHA1 intermediates is feasible. I do think 
requiring a constraint against general SHA1 intermediates (that lack technical 
restrictions to prevent server certs) is a good idea to ensure the 
intermediates are only used for s/MIME or code signing.

4) Documenting why outdated algorithms/key sizes/anything else are used always ends up 
being "For support of legacy devices". I don't see much value in that. It 
becomes an exercise in creating an automatic label applied to each certificate.

In all, I think clientAuth certs are different than serverAuth certs. CAs 
issuing clientAuth certs wouldn't necessarily be aware of the intent to 
deprecate.  I also do not think Mozilla has as large of stake in client 
certificates as it does server certs. Therefore, any plan to move away from 
SHA1 client certs should start with:
A) An announcement that client certs will be deprecated
B) A question to the public about what software is still requiring the use of 
SHA1 certs and the impact of requiring SHA2 certs, and
C) A date when SHA1 client certs will be deprecated

Again, I'm not opposed to moving to SHA2 client certs, but I don't think 
Mozilla has conveyed to the public its intent to do so.





I think Jeremy is correct, that Mozilla's previous communications about 
SHA-1 certs was only in regards to TLS/SSL certs.


Would anyone object to me changing Actions 1a and 1b to the following?
(note, using date 2016-04-01 for the CAs who don't have the Websites 
trust bit enabled will make it so we can easily filter out those responses)

~~
ACTION #1a: As previously communicated, CAs should no longer be issuing 
SHA-1 certificates chaining up to root certificates included in 
Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as 
well as any intermediate certificates that they chain up to. Check your 
systems and those of your subordinate CAs to ensure that SHA-1 based 
TLS/SSL certificates chaining up to your included root certificates are 
no longer being issued, and that any such certificates issued after 
2016-01-01 have been revoked. Please enter the last date that a SHA-1 
based TLS/SSL certificate was issued that chained up to your root 
certificates included in Mozilla's program. If your included root 
certificates do not have the Websites trust bit enabled, then please 
enter 2016-04-01. (Required)



ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL 
certificates that chain up to your root certificates included in 
Mozilla's CA Certificate Program will either expire or be revoked. If 
your included root certificates do not have the Websites trust bit 
enabled, then enter 2016-04-01.


As previously communicated we plan to show the “Untrusted Connection” 
error whenever a SHA-1 certificate is encountered in Firefox after 
January 1, 2017.


We recommend that you put safeguards into place that will prevent the 
future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 
based intermediate certificates that chain up to your root certificates 
included in Mozilla's CA Certificate Program. (Required)


~~


I think we can keep Action 1c as-is, because option (d) should capture 
information about issuance of S/MIME certs.



Thanks,
Kathleen


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

Re: SHA-1 S/MIME certificates

[Jakob Bohm]

On 30/03/2016 22:53, Jeremy Rowley wrote:

I think a required move away from SHA1 client certs requires a bit more 
planning.

1) There hasn't been a formal deprecation of all SHA-1 certificates in any root 
store policy. There has been a formal deprecation by the CAB Forum of SHA1 
server certificates. Considering many of the client cert issuance is governed 
by various national schemes (FBCA in the US and the Qualified Cert program in 
the EU), care is necessary in enacting policies that impact the use of client 
certificates. Although I recognize the need for Mozilla to ensure a safe onine 
experience for all its users, I'm sure they don't want to undermine entire 
trust frameworks built on these certificates. (Yes, I know FBCA requires SHA2 
now).



OK, it seemed like others in this newsgroup/on this list were acting
like the deprecation by the CAB/F applied to non-TLS certificates.

My proposed rules were intended for an environment in which such
deprecation exists.


2) The browsers are already deploying code to reject SHA1 certificates 
encountered. If this is true, what is the harm in continued SHA1 client 
certificate issuance until the national schemes have all updated their 
requirements? Mozilla is protected but the national bodies (and financial 
institutions) can continue using their software for client authentication. I do 
think we should move to SHA2, but I don't think the prior notice has occurred 
with respect to SHA1 client certs.



Indeed, hence the proposed requirements to clearly isolate SHA1
certificates to old SHA1 roots, especially considering the existence of
other trust lists than the one from Mozilla, and other X.509
implementations than the one written by Mozilla (Considering the
likelihood/fact of other implementations only deprecating SHA1 at
specific chain levels).


3) Because Mozilla doesn't have a policy against reissuance of SHA1 
intermediates for client certificates, I don't think your suggestion to only 
permit reissuance of limited SHA1 intermediates is feasible. I do think 
requiring a constraint against general SHA1 intermediates (that lack technical 
restrictions to prevent server certs) is a good idea to ensure the 
intermediates are only used for s/MIME or code signing.



Again the proposal was for an environment where such (re)issuance would
otherwise be deprecated and discouraged.

The phrasing was intended to permit the level of technical restrictions
relevant to the uses that would be documented.  For example some subCAs
could be restricted to S/MIME only (think e-mail only subCAs target at
older e-mail clients enumerated in the reason text).  Some other subCAs
could be restricted to e.g. C=US subjects doing TLS client auth (for
use with a specific broken US government services enumerated in the
reason text) etc.


4) Documenting why outdated algorithms/key sizes/anything else are used always ends up 
being "For support of legacy devices". I don't see much value in that. It 
becomes an exercise in creating an automatic label applied to each certificate.



The phrasing was intended to require more specific reasons, naming the
relevant "legacy devices" and/or "legacy software", with different
SubCAs for different groups of such legacy parties.  This in turn would
be intended to facilitate easy determination of when the various
categories of legacy parties cease to exist in practice.

Other proposed rules were about establishing practices that prevent the
various known types of attacks on SHA-1 and other recently broken hash
algorithms, such that it becomes less likely that someone would
succesfully request a certificate or other SHA-1 signed message on data
specially constructed to allow the attacker to convert this into
something that the CA would never have signed.

Those more informed than me about the workings of the known attacks
should check the sufficiency of these rules in stopping the known
attacks (including almost-ready attacks likely to become reality soon).



In all, I think clientAuth certs are different than serverAuth certs. CAs 
issuing clientAuth certs wouldn't necessarily be aware of the intent to 
deprecate.  I also do not think Mozilla has as large of stake in client 
certificates as it does server certs. Therefore, any plan to move away from 
SHA1 client certs should start with:
A) An announcement that client certs will be deprecated


If not yet made, I would expect such an announcement to be forthcoming
from someone.


B) A question to the public about what software is still requiring the use of 
SHA1 certs and the impact of requiring SHA2 certs, and


I believe that some CAs have already done a lot of published research
on this issue.  For instance GlobalSign has published their findings on
their web page, and my examples were based on my (imperfect)
recollection of that page.


C) A date when SHA1 client certs will be deprecated

Again, I'm not opposed to moving to SHA2 client certs, but I don't think 
Mozilla has conveyed to 

RE: SHA-1 S/MIME certificates

[Jeremy Rowley]

I think a required move away from SHA1 client certs requires a bit more 
planning.

1) There hasn't been a formal deprecation of all SHA-1 certificates in any root 
store policy. There has been a formal deprecation by the CAB Forum of SHA1 
server certificates. Considering many of the client cert issuance is governed 
by various national schemes (FBCA in the US and the Qualified Cert program in 
the EU), care is necessary in enacting policies that impact the use of client 
certificates. Although I recognize the need for Mozilla to ensure a safe onine 
experience for all its users, I'm sure they don't want to undermine entire 
trust frameworks built on these certificates. (Yes, I know FBCA requires SHA2 
now). 

2) The browsers are already deploying code to reject SHA1 certificates 
encountered. If this is true, what is the harm in continued SHA1 client 
certificate issuance until the national schemes have all updated their 
requirements? Mozilla is protected but the national bodies (and financial 
institutions) can continue using their software for client authentication. I do 
think we should move to SHA2, but I don't think the prior notice has occurred 
with respect to SHA1 client certs. 

3) Because Mozilla doesn't have a policy against reissuance of SHA1 
intermediates for client certificates, I don't think your suggestion to only 
permit reissuance of limited SHA1 intermediates is feasible. I do think 
requiring a constraint against general SHA1 intermediates (that lack technical 
restrictions to prevent server certs) is a good idea to ensure the 
intermediates are only used for s/MIME or code signing. 

4) Documenting why outdated algorithms/key sizes/anything else are used always 
ends up being "For support of legacy devices". I don't see much value in that. 
It becomes an exercise in creating an automatic label applied to each 
certificate. 

In all, I think clientAuth certs are different than serverAuth certs. CAs 
issuing clientAuth certs wouldn't necessarily be aware of the intent to 
deprecate.  I also do not think Mozilla has as large of stake in client 
certificates as it does server certs. Therefore, any plan to move away from 
SHA1 client certs should start with:
A) An announcement that client certs will be deprecated
B) A question to the public about what software is still requiring the use of 
SHA1 certs and the impact of requiring SHA2 certs, and
C) A date when SHA1 client certs will be deprecated 

Again, I'm not opposed to moving to SHA2 client certs, but I don't think 
Mozilla has conveyed to the public its intent to do so.


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jakob Bohm
Sent: Wednesday, March 30, 2016 12:06 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: SHA-1 S/MIME certificates

On 30/03/2016 18:49, Kathleen Wilson wrote:
> All,
>
> In response to the 'March 2016 CA Communication' I received the 
> following question from a CA. I think we should discuss it here, 
> because I suspect there will be other CAs in this same situation.
>
>  > We have a problem since we still issue SHA-1 S/MIME  > 
> certificates. Do we really have to stop issue after 2017?
>
> I will appreciate your thoughtful and constructive input into setting 
> reasonable expectations for CAs in regards to SHA-1 S/MIME certificates.
>
> Thanks,
> Kathleen

I would suggest the following minimum requirements:

1. Any 3rd party certificates using outdated certificate signing
   algorithms (such as certificates signed using SHA-1) must be issued
   under dedicated subCAs with as many technical constraints in the
   subCA's certificate validity as possible, such as restrictions in key
   usage, extended key usage, subCA validity period and distinguished
   name ("path name restrictions").  Mozilla will allow the issuing and
   reissuing of a reasonably low number of such SubCAs, provided they
   chain only through and to certificates that use the same or older
   outdated signing algorithm.  (For example SHA-1 certificates should
   be issued by a technically restricted SHA-1 SubCA that chains to an
   old SHA-1 (or older) root cert).

2. Any 3rd party certificates using outdated certificate signing
   algorithms (such as certificates signed using SHA-1) must include CA
   generated random values that are not known by the 3rd party prior to
   issuance (and thus prior to request generation).  Any such random
   values must contain the same number of bits as the signing hash (e.g.
   20 bytes/160 bits for SHA-1 signed certificates).  Any such random
   values must occur before most (preferably all) 3rd party supplied
   fields to protect against prefix collision based attacks.  In
   practice, placing the first 160 random bits in the certificate serial
   number, adding the next 12 random bits to the "NotBefore time" as a
   count of seconds, the next 12 random bits to the "NotAfter time" as 

Re: SHA-1 S/MIME certificates

[Jakob Bohm]

On 30/03/2016 18:49, Kathleen Wilson wrote:

All,

In response to the 'March 2016 CA Communication' I received the
following question from a CA. I think we should discuss it here, because
I suspect there will be other CAs in this same situation.

 > We have a problem since we still issue SHA-1 S/MIME
 > certificates. Do we really have to stop issue after 2017?

I will appreciate your thoughtful and constructive input into setting
reasonable expectations for CAs in regards to SHA-1 S/MIME certificates.

Thanks,
Kathleen


I would suggest the following minimum requirements:

1. Any 3rd party certificates using outdated certificate signing
  algorithms (such as certificates signed using SHA-1) must be issued
  under dedicated subCAs with as many technical constraints in the
  subCA's certificate validity as possible, such as restrictions in key
  usage, extended key usage, subCA validity period and distinguished
  name ("path name restrictions").  Mozilla will allow the issuing and
  reissuing of a reasonably low number of such SubCAs, provided they
  chain only through and to certificates that use the same or older
  outdated signing algorithm.  (For example SHA-1 certificates should
  be issued by a technically restricted SHA-1 SubCA that chains to an
  old SHA-1 (or older) root cert).

2. Any 3rd party certificates using outdated certificate signing
  algorithms (such as certificates signed using SHA-1) must include CA
  generated random values that are not known by the 3rd party prior to
  issuance (and thus prior to request generation).  Any such random
  values must contain the same number of bits as the signing hash (e.g.
  20 bytes/160 bits for SHA-1 signed certificates).  Any such random
  values must occur before most (preferably all) 3rd party supplied
  fields to protect against prefix collision based attacks.  In
  practice, placing the first 160 random bits in the certificate serial
  number, adding the next 12 random bits to the "NotBefore time" as a
  count of seconds, the next 12 random bits to the "NotAfter time" as a
  count of seconds and inserting any remaining bits as an early element
  in the subject distinguished name would be the closest allowed by
  X.509v3 and older.

3. Document, for each such external usage the exact technical reason
  why subscribers are presumed unable to use certificates using modern
  algorithms.  For example: "These certificates are for US medical
  persons needing access to the US FDA server at foo.bar.gov, which
  does not accept better algorithms" .  Or "These certificates are
  exclusively for users communicating with users of the Microsoft
  Office 2007 Outlook MUA, which does not support better algorithms"

4. Any CA internal certificates using outdated certificate signing
  algorithms (such as certificates signed using SHA-1) must be issued
  in a very minimal count and with short validity periods (1 to 16
  months), even though this would imply more frequent reissuing.  Any
  such internal CA certificates must serve a specific purpose in
  servicing existing or acceptable certificates using such algorithms,
  such as OCSP signing, online timestamping or the restricted subCAs
  specified by rule 1 above).  Additional administrative procedures
  must be used to prevent the internal requests for such certificates
  from being generated with malicious content, for example they might
  be generated only by specially trusted hardware with private keys
  securely transported to the point of usage after issuance.

5. Any other CA usage of outdated signing algorithms in signatures
  traceable to Mozilla trusted roots must be done in the minimal count
  possible and only to serve a specific purpose in servicing existing
  or acceptable certificates using such algorithms, such as CRL signing
  or OCSP signing where a documented technical reason must be given for
  not making such signatures using dedicated certificates (for example,
  a specific named client implementation might fail to accept OCSP
  responses and/or CRL signatures not signed directly by the CA).
   As an example of reducing the frequency of such signatures, CRLs
  might be issued with longer than usual refresh intervals for older
  CAs that have few remaining valid certificates and are mostly
  reissuing CRLs to provide trusted lists of historic revocation dates.

6. Any other CA usage of outdated signing algorithms in signatures
  traceable to Mozilla trusted roots must include CA generated random
  values that are not known by the 3rd party prior to issuance (and
  thus prior to request generation). Any such random values must
  contain the same number of bits as the signing hash (e.g. 20
  bytes/160 bits for SHA-1 signed certificates). Any such random
  values must occur before most (preferably all) 3rd party supplied
  data elements to protect against prefix collision based attacks.  For
  example CRLs could include revocation of one or more never-issued
  certificates with random serial 

Re: SHA-1 S/MIME certificates

[Kathleen Wilson]

I am, indeed, receiving this question from multiple CAs.

As for responding to the survey, note that Action #1a and Action #1b ask for 
dates regarding SHA-1 SSL certs (unless their included root certs do not have 
the Websites trust bit set).

"ACTION #1a: ...  Please enter the last date that a SHA-1 based TLS/SSL 
certificate was issued that chained up to your root certificates included in 
Mozilla's program. ..."

"ACTION #1b: ... Enter the date when all of the SHA-1 based TLS/SSL 
certificates that chain up to your root certificates included in Mozilla's CA 
Certificate Program will either expire or be revoked. ..."

ACTION #1c is where CAs should provide information about their plans regarding 
SHA-1 S/MIME certificates, and any other types of SHA-1 certificates still 
being issued that chain up to the CA's included root certificates.

I will greatly appreciate your input as to what would be reasonable 
expectations for CAs in regards to SHA-1 S/MIME certificates.

Thanks,
Kathleen


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

SHA-1 S/MIME certificates

[Kathleen Wilson]

All,

In response to the 'March 2016 CA Communication' I received the 
following question from a CA. I think we should discuss it here, because 
I suspect there will be other CAs in this same situation.


> We have a problem since we still issue SHA-1 S/MIME
> certificates. Do we really have to stop issue after 2017?

I will appreciate your thoughtful and constructive input into setting 
reasonable expectations for CAs in regards to SHA-1 S/MIME certificates.


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

Re: ComSign Root Renewal Request

[Eli Spitzer]

On Wednesday, March 30, 2016 at 4:36:44 AM UTC+3, Andrew Whalley wrote:
> Hello Jesus,
> 
> Great points!
> 
> > Reviewing the BR audit report of Comsign Ltd I have a few doubts regarding 
> > the audits accepted by Mozilla and may someone can help me.
> > 
> > The BR audit was conducted according to the WebTrust forCertification 
> > Authorites - SSL Baseline Requirements Audit Criteria version 1.1 and it's 
> > a point-of-time (as of April 26, 2015).
> > Although this audit criteria is accepted according to the Mozilla CA 
> > Certificate Inclusion Policy 2.2, the BR audit version 1.1 was superseded 
> > by Webtrust SSL Baseline with Network Security version 2.0 (effective for 
> > audit periods starting on or after July 1, 2014).
> > 
> > Webtrust audit criteria states that "The point-in-time readiness assessment 
> > shall be completed no earlier than twelve (12) months prior to issuing 
> > Publicly-Trusted Certificates and shall be followed by a complete audit 
> > under such scheme within ninety (90) days of issuing the first 
> > Publicly-Trusted Certificate. (See SSL Baseline Requirements Section 
> > 17.4)". Should Mozilla expect a complete audit 90 days after the 
> > point-in-time BR audit report or after the first certificate (I don't know 
> > when was issued)?
>  
> Neither of the other audit reports I can find by Sharony - Shefler & Co, for 
> "ComSign CA" (https://bugzilla.mozilla.org/attachment.cgi?id=868616) and 
> "Comsign Secured CA" 
> (https://bugzilla.mozilla.org/attachment.cgi?id=8686170), give an audit 
> duration and only state a point in time.
> 
> Eli, please confirm when we can expect a period audit and what period it will 
> cover.
> 
> > In addition and regarding the OCSP Responder certificate with Serial 
> > Number: 0e:2b:cd:a4:aa:4f:8f:80:da:16:94:4e:ba:33:35:33, the validity is 3 
> > years. According the RFC 6960 "A CA may specify that an OCSP client can 
> > trust a responder for the lifetime of the responder's certificate.  The CA 
> > does so by including the extension id-pkix-ocsp-nocheck.  This SHOULD be a 
> > non-critical extension. The value of the extension SHALL be NULL. CAs 
> > issuing such a certificate should realize that a compromise of the 
> > responder's key is as serious as the compromise of a CA key used to sign 
> > CRLs, at least for the validity period of this certificate.  CAs may choose 
> > to issue this type of certificate with a very short lifetime and renew it 
> > frequently." Which is the maximum acceptable lifetime for this type of 
> > certificates that contains the id-pkix-ocsp-nocheck extension?
> 
> Three years seems excessive, but doesn't appear to be uncommon:
> 
> http://ocsp.entrust.net 
> Not Before: Jun  4 19:15:34 2015 GMT
> Not After : Jun  4 19:45:34 2017 GMT
> 
> http://crl.quovadisglobal.com/qvocag2.crl
> Not Before: May 28 14:33:37 2014 GMT
> Not After : May 28 14:33:37 2017 GMT
> 
> And there are some are valid for much longer:
> 
> http://root-c3-ca2-2009.ocsp.d-trust.net
> Not Before: Jul  2 10:03:07 2013 GMT
> Not After : Nov  5 08:35:58 2029 GMT
> 
> It sounds like limiting the validity period of OCSP signing certs would be an 
> excellent topic to discuss generally, but I don't consider it a blocking 
> issue for this application.
> 
> Andrew

Hello Andrew and Jesus,
As mentioned, the Audit reports that we have are only Point-in-Time reports. We 
haven't started issuing public certificates yet, and at the moment we are not 
planning to do so until the inclusion in the Mozilla Root program.
Once we finish the inclusion process and start issuing public certificates we 
will conduct a period audit as required by WebTrust BR
Eli
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: A-Trust Root Renewal Request

[Andrew Whalley]

Hello,

Given the numerous problems discovered so far, including several that contract 
the explicit declaration made to Mozilla [1], I would not feel comfortable 
supporting the application at this juncture.

My next step would be to go though the CP/CPS with a fine-tooth comb, but alas 
my schoolboy German isn't up to the task.  I would be most grateful if a 
translation into English - attested as accurate by A-Trust - could be made 
available.

I also note the test site https://ca-train.a-trust.at is unreachable.

Cheers,

Andrew

[1] See the "CA's Response to Problematic Practices" section of 
https://bugzilla.mozilla.org/attachment.cgi?id=8668186)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy