On Fri, 16 Dec 2016 02:51:47 +0100
Jakob Bohm wrote:
> I believe it would cause a problem with legacy systems that don't
> understand SHA-256 signatures at all, noting that such systems will
> only ever trust SHA-1 (and older) certificates, thus SHA-1 signing can
> be limited to cases where the C
Hanno Böck schrieb:
> I believe the potential problem is a different one: Systems that accept
> SHA256 on certificate signatures, but not on OCSP responses. I don't
> know if such systems exist, but if I had to make a bet I'd say they do.
Roland does not talk about signature algorithms. He is cons
On 16/12/2016 13:34, Jürgen Brauckmann wrote:
Hanno Böck schrieb:
I believe the potential problem is a different one: Systems that accept
SHA256 on certificate signatures, but not on OCSP responses. I don't
know if such systems exist, but if I had to make a bet I'd say they do.
Roland does not
On 16/12/2016 12:22, Hanno Böck wrote:
On Fri, 16 Dec 2016 02:51:47 +0100
Jakob Bohm wrote:
[Snip: Discussion of potential odd client bug]
...
I wonder if Let's Encrypt ever issued SHA-1 certificates, and if any
of those are non-expired.
Almost certainly not. Given 3 month lifetime of cert
On 10/12/16 21:14, Brian Smith wrote:
> "Unable to issue" means "unable to sign with the private key" which
> can only happen if they don't have the private key. But they do have
> the private key so they're always able to issue certificates with any
> contents they want. Thus "unable to issue" is
On 10/12/16 21:25, Brian Smith wrote:
> Again, it doesn't make sense to say that the forms of names matter for
> name constraints, but don't matter for end-entity certificates. If an
> end-entity certificate doesn't contain any names of the forms dNSName,
> iPAddress, SRVName, rfc822Name, then it s
On 08/12/16 20:47, Gervase Markham wrote:
> Proposal: update the second bullet in point 3 of the Maintenance section
> so that the last sentence reads:
>
> OCSP responses from this service must have a defined value in the
> nextUpdate field, and it must be no more than ten days after the
> thisUpd
On 08/12/16 20:48, Gervase Markham wrote:
> Require CAs to publish their CPs and CPSes under one of the following
> Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND.
>
> This is so that there is no legal impediment to their proper storage,
> scrutiny etc. by relying parties.
>
> Proposal: a
On 14/12/16 23:13, Eric Mill wrote:
> Sure, that works. Is the "in writing" part necessary? You might say instead
> "publicly accepted by Mozilla.", which would imply text on m.d.s.p or
> bugzilla that would necessarily be in writing, while also ensuring better
> visibility.
I'm not sure what you
When an OCSP response signing certificate expires before the OCSP
responses signed by the certificate expire, multiple websites break,
particularly sites that use OCSP stapling. Make it a requirement that
every OCSP response must have a nextUpdate field that is before or equal
to the notAfter date
Currently, the policy says:
"all new end-entity certificates must contain at least 20 bits of
unpredictable random data (preferably in the serial number)."
We should require the random data to be in the serial number, and also
update the number of bits required.
BRs 1.3.7 and later say:
"Effect
The word "misused" in the policy could do with clarifying. The
Maintenance Policy states:
"2. CAs must revoke Certificates that they have issued upon the
occurrence of any of the following events: ... the CA obtains reasonable
evidence that the subscriber’s private key (corresponding to the public
On 2016-12-16 15:45, Gervase Markham wrote:
But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
trust cert chains that rely on it, so there's no need to ban it. Is there?
Can I point out again that Firefox (or NSS) is not the only user of the
root store?
Kurt
On Fri, Dec 16, 2016 at 7:24 AM, Kurt Roeckx wrote:
> On 2016-12-16 15:45, Gervase Markham wrote:
>>
>> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
>> trust cert chains that rely on it, so there's no need to ban it. Is there?
>
>
> Can I point out again that Firefox (o
Den 15-12-2016 kl. 00:12 skrev Kathleen Wilson:
1) Salesforce (in cloud) is using the default Java root store, which is smaller than
Mozilla's root store. This accounts for the
"sun.security.validator.ValidatorException: PKIX path building failed:" errors.
We're not yet sure how to tell the Jav
So here we are, three months later, First Data are back, as predicted, asking
for another "exception".
First Data's original notice seeking the exception asserts that staging
environments for these systems had SHA-256 certificates from November
2014 giving their VARs plenty of time to react.
Act
It seams that wosign has registered the domains letsencrypt.cn and
letsencrypt.com.cn in 2014 after the public announce of Let's Encrypt :
whois letsencrypt.cn
Domain Name: letsencrypt.cn
ROID: 20141120s10001s72911711-cn
Domain Status: clientTransferProhibited
Registrant ID: k35-n2041486_00
Regis
On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote:
> On Fri, Dec 16, 2016 at 7:24 AM, Kurt Roeckx wrote:
> > On 2016-12-16 15:45, Gervase Markham wrote:
> >>
> >> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
> >> trust cert chains that rely on it, so there's n
By the way Gerv, in your flurry of posts to CA/B Forum public you comment
"If I were going to calculate a SHA-1 collision, the certificate of a
machine handling tens or hundreds of thousands of credit cards a day
would be a reasonably obvious target, ISTM."
This would need a second pre-image attac
On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote:
>
> Not trying to be snarky - just that if we're going to act upon your
> comment, actionable data and concerns are needed.
>
> Put more concretely:
> - Hypotheticals ("What about software foo?") should not be considered
> unless they'r
On Fri, Dec 16, 2016 at 11:56 AM, Kurt Roeckx wrote:
> So I guess I should also reply to the rest here.
>
> I am a Debian Developer and an OpenSSL developer, but I'm not
> speaking in anybody's name. But I do want to represent concerns
> that the general open source community might have that just
On Fri, Dec 16, 2016 at 7:15 AM, Gervase Markham wrote:
> When an OCSP response signing certificate expires before the OCSP
> responses signed by the certificate expire, multiple websites break,
> particularly sites that use OCSP stapling. Make it a requirement that
> every OCSP response must have
Gervase Markham wrote:
> On 10/12/16 21:25, Brian Smith wrote:
>> Again, it doesn't make sense to say that the forms of names matter for
>> name constraints, but don't matter for end-entity certificates. If an
>> end-entity certificate doesn't contain any names of the forms dNSName,
>> iPAddress,
Well, based on the previous deception of WoSign before, during and after
Mozilla's investigation, I'm not remotely surprised to see this.
On Friday, December 16, 2016 at 10:18:27 AM UTC-8, tde...@gmail.com wrote:
> It seams that wosign has registered the domains letsencrypt.cn and
> letsencryp
24 matches
Mail list logo