Re: [cabfpub] EXTERNAL: CAB Forum Countdown to IPR Agreement deadline

[Mehner, Carl via Public]

Hi Virginia,

How do interested parties 1) access the wiki to get the new IPR, 2) get 
notified when the IPR is expiring so that they don’t miss out on signing it in 
time? 3) How would an interested party upload the signed agreement if they 
cannot access the wiki?

For #1, is that answer that the definitive version is on the main 
site,
 not the wiki? If so, there seem to be two v1.3’s on that site, with different 
effective dates. (the email-lists site 
points to the older of the two versions and has no instructions on where to 
send the signed agreement).


Thanks,
Carl Mehner

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Virginia 
Fournier via Public
Sent: Wednesday, April 18, 2018 1:53 PM
To: CA/Browser Forum Public Discussion List 
Subject: EXTERNAL: [cabfpub] CAB Forum Countdown to IPR Agreement deadline

75 days until July 3, the deadline to get your IPR Agreement signed and 
submitted.

Here’s the wiki url, where you can download the IPR Policy v. 1.3 and the IPR 
Policy Agreement, and upload your signed agreement.

https://www.cabforum.org/wiki/Intellectual%20Property%20Rights

Don’t wait until the last minute!


Best regards,

Virginia Fournier
Senior Standards Counsel
 Apple Inc.
☏ 669-227-9595
✉︎ v...@apple.com





___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

[Mehner, Carl via Public]

To Ryan’s point on relevance, even if it were relevant to the arguments in 
play, that document says 1-2 years for an authentication key (what I would 
classify this as) or Private Key Transport Key / Public Static Key Agreement 
Key (in the event of RSA key exchange); 13 or even 15 months falls into the 
NIST timeframe, 27 – 39 months does not.

I would also agree with Peter’s assertion that most organizations would not (by 
software defaults or by security policy) re-use keys between certs.


From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Dean Coclin via 
Public
Sent: Tuesday, February 21, 2017 2:46 PM
To: CA/Browser Forum Public Discussion List ; Peter Bowen 

Cc: Dean Coclin 
Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

Not sure, I will pass on the question to ATT.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Tuesday, February 21, 2017 3:18 PM
To: Peter Bowen 
Cc: Ryan Sleevi ; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

Dean,

Can you share whether or not that was the case for AT&T?

On Tue, Feb 21, 2017 at 11:43 AM, Peter Bowen 
mailto:p...@amzn.com>> wrote:
   Many organizations have policies to not re-use keys between certificates.  
Dropping the validity period therefore effectively drops the key usage period.

  On Feb 21, 2017, at 10:54 AM, Ryan Sleevi via Public 
mailto:public@cabforum.org>> wrote:

  This doesn't seem particularly relevant - I haven't heard any suggestion 
that this is about ensuring frequent key rotation, as opposed to all the other 
policies and practices being attested to in conjunction with the keys.

  On Tue, Feb 21, 2017 at 10:52 AM, Dean Coclin via Public 
mailto:public@cabforum.org>> wrote:
 Posting on behalf of AT&T:

 AT&T typically looks to NIST for guidance and reference on industry 
standards, see page 45 of the attached (NIST SP800-57-Pt1R4) document.

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

[Mehner, Carl via Public]

“It would be helpful for a wide range of users (enterprises, non-profits, 
educational institutions, partners, resellers, device manufacturers) to provide 
input into this discussion to help the community formulate opinions on this 
major change.”

In an enterprise scenario, 1-year certs would make things better. We restricted 
all enterprise issuance to a max of 2 year certs simply because it was the 
minimum of the max-validity of EV and DV. What we later found is that 
sometimes, even after only 2 years, the people that originally 
installed/configured the certs did not remember how to install the cert on 
their platform, or aren’t on the same team anymore (and if they aren’t, they 
may not know who should be responsible). Most of that is easily corrected with 
documentation and process, but for the vast majority of people, certs aren’t 
their day to day life, and restricting to 1-year would assist in keeping the 
memories of installation and renewal at least a little fresher in their minds, 
help with budgeting, and of course, help the ecosystem overall.
To Doug’s earlier question, “If the cert is 1 year vs. 3 is there a 
difference?” Yes, (trying not to be too tongue and cheek..) there is. It’s a 
difference of 2 years of waiting before the browsers, CAs, and site operators 
can be assured that certificates that don’t meet standards/baselines are phased 
out, it allows everyone to move forward with more agility. In just one example, 
it’s a difference of knowing that in October of 2018, all publicly trusted 
certs (valid in Chrome) will be in CT logs, rather than waiting until October 
of 2020 to be in a place where a site operator can rely on that detective 
control for misissuance.
-Carl

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Dean Coclin via 
Public
Sent: Wednesday, February 01, 2017 3:02 PM
To: CA/Browser Forum Public Discussion List 
Cc: Dean Coclin 
Subject: EXTERNAL: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of 
Certificates

We’ve discussed certificate lifetimes at several F2F meetings and I especially 
recall the Zurich meeting where I tried to see where folks stand by putting up 
a chart with different options for cert lifetimes. As I recall , there was no 
consensus.

Some CAs were in favor of extending EV to 3 years but browsers made it clear 
that was not on the table. Some browsers talked about reducing all certs to 1 
year but many CAs said that would not be welcome by the vast majority of 
businesses that purchase and use certificates in various applications.

I seem to recall some CAs reaching out to enterprise customers to get their 
opinions. I have to dig a little deeper to find that information but maybe 
someone on the list has that readily available.

Is there some rationale for the 12/13 month selection? Why wasn’t 6/9/14/18 
months considered? It appears a balance is being sought but it is unclear what 
parameters are being weighed in this decision process.

It would be helpful for a wide range of users (enterprises, non-profits, 
educational institutions, partners, resellers, device manufacturers) to provide 
input into this discussion to help the community formulate opinions on this 
major change.

Dean

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Tuesday, January 31, 2017 10:50 PM
To: CABFPub 
Cc: Ryan Sleevi 
Subject: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

I'm looking for two endorsers to publicly endorse this ballot.

Background:
The validity period of certificates represents the single greatest impediment 
towards improving the security of the Web PKI. This is because it sets the 
upper-bound on when legacy behaviours may be safely deprecated, while setting a 
practical lower-bound for how long hacks and workarounds need to be carried 
around by clients.

Further, in the event of misissuance related to internal control failures, 
rather than external security failures - for example, misissuance due to 
failing to properly vet subject information - the validity period represents 
the risk and exposure to customers and relying parties in the absence of 
revocation information (for example, constrained environments).

To keep this vote simple, it avoids any discussion of the reuse of validation 
information, described in Section 4.2.1 of the Baseline Requirements and 
Section 11.14.3 of the EV Guidelines.



The following motion has been proposed by Ryan Sleevi of Google, Inc and 
endorsed by ___ of ___ and ___ of ___ to introduce new Final Maintenance 
Guidelines for the "Baseline Requirements Certificate Policy for the Issuance 
and Management of Publicly-Trusted Certificates" and the "Guidelines for the 
Issuance and Management of Extended Validation Certificates"

-- MOTION BEGINS --
Modify Section 6.3.2 of the "Baseline Requirements Certificate Policy for the 
Issuance and Management of Publicly-Trusted Certificates" as follows:

Replace Section 6.3.2 with

Re: [cabfpub] EXTERNAL: Re: Continuing the discussion on CAA

[Mehner, Carl via Public]

> On 24/10/16 16:40, Jeremy Rowley via Public wrote:
> > Has there been an issuance to a third party that CAA would have
> prevented?

We have an internal policy that describes which CAs are allowed for use, there 
have been cases where other teams or entities have issued a certificate that 
did not fit within our defined policy. Had CAA enforcement been enabled and the 
CAs set to hard-fail mode, what we see as a "semantic mis-issuance" [1] would 
not have occurred.


> 2) If a customer has a single base domain and needs to issue 6 million certs 
> an hour for the various sub domains, then there isn't a way for the CA to 
> simply accept the base domain's CAA record.
I think that hanging on to responses for a short amount of time would be good 
for multiple issuances within time period 'X' like in 

However, as it says in RFC6844:
CAA records MAY be used by Certificate Evaluators as a possible
   indicator of a security policy violation.  Such use SHOULD take
   account of the possibility that published CAA records changed between
   the time a certificate was issued and the time at which the
   certificate was observed by the Certificate Evaluator.

Therefore, when a cached CAA response is 're-checked' and the status has 
changed, that must not in and of itself constitute an event worthy of 
revocation under 4.9.1.1.12 of the BRs.


[1] https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-10#section-3

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] SHA-1 exception request

[Mehner, Carl via Public]

> Or do you have some requirements, e.g. PCI compliance?
> 
> [First Data] Yes there are PCI requirements that must be met. As pointed out
> by Peter Bowen, those requirements have not yet prohibited SHA-1
> certificates.

I think that's a miscategorization of what Peter said. He was simply stating 
what is included in documents on a specific company's website.

[[ Please note that I am not a QSA, and you should consult your own QSA 
for PCI related things... however, I believe the following is logical. ]]

PCI has not specifically allowed or rejected the use of SHA-1 hashes.
But, PCI does require "strong cryptography", of which hashes are a subset.

Specifically, in the DSS v3.2, it says "Use strong cryptography and security 
protocols" and to ensure "Only trusted keys and certificates are accepted"
Strong cryptography is defined as "Cryptography based on industry-tested and 
accepted algorithms, along with strong key lengths (minimum 112-bits of 
effective key strength)"
It then points to NIST SP 800-57 part 1 for clarification.
NIST SP 800-57 part 1 (rev 4) says in Table 3 that SHA-1 has less than or 
equal to 80-bits of security and points to NIST 800-107 for the security 
implications of the hash algorithms. 800-107 says, "SHA-1 is not suitable for 
general-purpose digital signature applications (as specified in FIPS 186-3) 
that require 112 bits of security"

NIST SP 800-175B backs that up saying, "Note that attacks on SHA-1 have 
indicated that SHA-1 provides less security than originally thought when 
generating digital signatures [...] consequently, SHA-1 is now disallowed for 
that purpose"

Therefore, an argument can be made that a new SHA-1 signature for a 
certificate is prohibited by PCI.

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public