On 10/10/16 23:01, Peter Bowen wrote:
> While I think the IETF is the right place for technical work on redaction,
> the IETF explicitly avoids work on policy.
>
> In the realm of CT, 6962bis section 4.2 includes the option to log a
> name-constrained intermediate CA in place of logging end-en
Dear CAB Forum,
I have been doing some research recently into how the different browsers
produced by CAB Forum members treat various forms of bad SSL. You can
find it here:
https://docs.google.com/document/d/1b7lenmn5XO06QohaJzVffnJxjXjY1rD70wg34gfuxRo/edit#
The results may have implications for
I think the discussion would be better led by somebody who is more
motivated to solve the policy issues relating to redaction. Rick just
posted a lengthy message about Recourse for domain owners, so I nominate
him. ;-)
As Ryan noted, redaction will undoubtedly come up in the Browser News
slot an
Hi Peter,
> -Original Message-
> Peter Bowen said on 30 September 2016
> In reviewing the Baseline Requirements and certain trust store
> requirements, I ran into a set of questions I’m hoping someone can answer.
>
> The BRs have several sections that address CA key protection. The ones
While I understand the IETF doesn't work on policy, I meant to suggest that
the most important aspect - which absolutely belongs in the IETF - is use
cases.
I do not believe we can have a meaningful discussion of policy without
understanding use cases. It's clear that the technical solutions explo
This likely dates from the time that NIST had decided to EOL the RSA algorithm
and push everyone towards Elliptic Curves. Now that Quantum is looming as a
more likely threat than a new factoring technique they are rowing back in the
opposite direction.
FIPS can be changed. I suggest that CABFor
Afternoon everyone,
Unofficial response from a POC at NIST.
One option would be to try to find a FIPS 140 validated module that has been
validated for 4096-bit RSA signature generation. As noted, it would have to be
an older module. However, according to
http://csrc.nist.gov/groups/STM/cavp/do
Here is the proposed agenda for our teleconference this Thursday at 16:00
UTC (9:00 Pacific, Noon Eastern, 17:00 London)
Time
Start (UTC)
Stop
Slot
Description
Notes / Presenters
(Thur) 13 October 2016
0:02
16:00
16:02
1
Roll Call
Dean
0:01
16:02
16:03
2
R
On Mon, Oct 10, 2016 at 8:34 PM, Peter Bowen via Public wrote:
>
> > On Oct 10, 2016, at 5:31 PM, public@cabforum.org wrote:
> >
> > During the discussions about CT name redaction ([1], [2]), it became
> clear
> > that there is no formal policy regarding what actions a CA should take
> if a
> > d
I may be misunderstanding what you are saying, but I wasn't going to start the
30/60 day Review period until after 7 days discussion and success on a 7 day
straw poll. Then the 30/60 day Review period, then straight to a real vote for
adoption. Shortest period start to finish would be 51 days.
> On Oct 11, 2016, at 2:30 PM, Ryan Sleevi wrote:
>
>
>
> On Mon, Oct 10, 2016 at 8:34 PM, Peter Bowen via Public
> wrote:
>
> > On Oct 10, 2016, at 5:31 PM, public@cabforum.org wrote:
> >
> > During the discussions about CT name redaction ([1], [2]), it became clear
> > that there is no fo
On Tue, Oct 11, 2016 at 5:26 PM, Peter Bowen wrote:
>
> You are conflating two things here. "it's perfectly acceptable for the
> domain operator to be distinct from the certificate applicant” - Yes.
> Akamai or Fastly (or any CDN) can apply for a certificate for a domain
> registered to one of t
As I read through the string, remember that we all have a Privacy Policy (BR
9.4 covers this, although we presently have no BR stipulations on privacy
policies). So whatever we decide to do in responding to information requests
from claimed domain owners will have to comply with our individual
Kirk,
The point is to remove the degree of "CA discretion" that you suggest, to
ensure there's a normalized, reasonable, and reliable set of options for
domain holders. As Rick noted in the introduction, this is certainly one of
the concerns with allowing redaction.
For example, it would be undes
Francisco,
What is the status of the revised newgtlds v2 file you presented a while back?
I’ve noticed multiple TLDs have now been retired, and others seem to have never
made it to the root zone before being removed from the newgtlds.csv file, so
having the updated version would be helpful.
T
15 matches
Mail list logo
