Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

[Simone Carletti via dev-security-policy]

> Yeah, I completely get how that would happen. I would just think this is
a good learning opportunity to protect against ambiguously written text by
giving a day's buffer.

I absolutely agree Eric, and this is the primary reason I'm sharing this
issue here.
I am playing the role of a CA and Browser user here, speaking on behalf of
our customer. Our customer is the party that eventually is affected by this
misunderstanding.

We placed a request with Comodo to get this certificate order refunded and
place a new order (as it stands today it's unusable and I assume we can't
reissue it with a 3 years length at this point). I'm confident that we'll
sort this out, but I wanted to bring up this issue to encourage less
ambiguous wording in the future.

-- Simone


On Sun, Apr 22, 2018 at 2:10 PM, Eric Mill  wrote:

>
>
> On Sun, Apr 22, 2018 at 5:01 PM, Rob Stradling  wrote:
>
>> On 22/04/18 21:04, Eric Mill via dev-security-policy wrote:
>>
>>> On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> First of all, it's important to distinguish between the BR r
 But even if you accept my premise there, then you have to ask "in what
 timezone?"  March 1 00:00:00 2018 GMT in North America is February 28.
 So
 I could see someone making the argument that issuance at that moment in
 time is fine if the CA is in North America but it's mis-issuance if the
 CA
 is in Europe, since the requirements don't state that the measurement is
 UTC.  This is why I'm not a fan of such precise enforcements of
 date-related compliance.  There are a lot of different ways to interpret
 dates/times, but none of the readings materially change the net effect
 of
 the rule.  That is, all readings change the max validity period to ~825
 days (which itself is subject to debate as to its precise meaning in
 terms
 of seconds) within a day or two of each other.  So, enforcing the date
 as
 Mar 1 as opposed to Mar 2 doesn't seem to add a lot of value and leads
 to
 confusion like this.

>>>
>>> I'm just going to double down on Matt's comment that the problem here
>>> doesn't seem to be in strictness of enforcement, but rather CAs leaving
>>> themselves no buffer zone.
>>>
>>
>> The problem here, IMHO, is that the BR requirement was poorly written.
>>
>> Whatever business advantage there is of giving
>>> customers that one last day to get 3-year certs, seems likely not as
>>> valuable as the certainty of avoiding giving those customers errors when
>>> the certs are used in major browsers.
>>>
>>
>> The certainty?  Hindsight is a wonderful thing.  When I wrote Comodo CA's
>> code to enforce the "after 1 March 2018" rule, this "certainty" did no
>> occur to me.  I simply read the BR requirement and then implemented code to
>> enforce it.
>
>
> Yeah, I completely get how that would happen. I would just think this is a
> good learning opportunity to protect against ambiguously written text by
> giving a day's buffer.
>
> Tim's time zone example is another good reason to give that buffer, even
> if the BR language made it clear whether it was > or >=. A tangentially
> similar comparison would be that in other systems I've built that structure
> search results and push notifications around dates, the only safe way to do
> it is to assign times as 12:00 UTC, even if that doesn't really accurately
> describe the time something happened, so that no matter what time zone
> someone is in, they're guaranteed to see it as the same day. It's worth the
> imprecision to create consistency.
>
>
>>
>>
>> -- Eric
>>>
>>>
>>>
 On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti
 via dev-security-policy"  wrote:

  Hello,

  I'm investigating an issue on behalf of a customer. Our customer
 requested a multi-year certificate that was issued on March 1st by
 Comodo.

  Here's the certificate:
  https://crt.sh?id=354042595

  Validity
  Not Before: Mar  1 00:00:00 2018 GMT
  Not After : May 29 23:59:59 2021 GMT

  The certificate is currently considered invalid at least by Google
 Chrome.

  It's my understanding that Google Chrome uses a >= comparison,
 which
 effectively means certificates issued on March 1st are already subject
 to
 Ballot 193.

  However, it looks like the interpretation of Comodo of Ballot 193
 here
 is based on a > comparison, since the certificate was issued with a 3y
 validity.

  BR 6.3.2 says:

  > Subscriber Certificates issued after 1 March 2018 MUST have a
 Validity Period no greater than 

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[pfuentes69--- via dev-security-policy]

I think you should consider an an exception Issuing CAs including Name 
Constraints. This would keep allowing root signing services for corporate CAs 
without forcing multiple CAs.

El viernes, 20 de abril de 2018, 23:03:17 (UTC+2), Wayne Thayer  escribió:
> On Thu, Apr 19, 2018 at 8:40 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On 17/04/2018 20:24, Wayne Thayer wrote:
> >
> >> This proposal is to require intermediate certificates to be dedicated to
> >> specific purposes by EKU. Beginning at some future date, all newly created
> >> intermediate certificates containing either the id-kp-serverAuth or
> >> id-kp-emailProtection EKUs would be required to contain only a single EKU.
> >>
> >> Arguments for this requirement are that it reduces risk of an incident in
> >> which one type of certificate affecting another type, and it could allow
> >> some policies to be restricted to specific types of certificates.
> >>
> >>
> > One case that needs to be considered is specifying a set of closely
> > related EKUs, which are desirable to include in the same end entity
> > certificate.  A typical combination would be emailProtection and
> > clientAuth, for the same identity in the EE cert.
> >
> > I believe the language I proposed takes care of this:
> https://github.com/mozilla/pkipolicy/commit/1ccf31557932ede045f3c2d7bcdac533c5176f18
> 
> If there are no additional comments, I will consider this issue to be
> resolved and will include this change in version 2.6 of the policy.
> 
> - Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

[Eric Mill via dev-security-policy]

On Sun, Apr 22, 2018 at 5:01 PM, Rob Stradling  wrote:

> On 22/04/18 21:04, Eric Mill via dev-security-policy wrote:
>
>> On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> First of all, it's important to distinguish between the BR r
>>> But even if you accept my premise there, then you have to ask "in what
>>> timezone?"  March 1 00:00:00 2018 GMT in North America is February 28.
>>> So
>>> I could see someone making the argument that issuance at that moment in
>>> time is fine if the CA is in North America but it's mis-issuance if the
>>> CA
>>> is in Europe, since the requirements don't state that the measurement is
>>> UTC.  This is why I'm not a fan of such precise enforcements of
>>> date-related compliance.  There are a lot of different ways to interpret
>>> dates/times, but none of the readings materially change the net effect of
>>> the rule.  That is, all readings change the max validity period to ~825
>>> days (which itself is subject to debate as to its precise meaning in
>>> terms
>>> of seconds) within a day or two of each other.  So, enforcing the date as
>>> Mar 1 as opposed to Mar 2 doesn't seem to add a lot of value and leads to
>>> confusion like this.
>>>
>>
>> I'm just going to double down on Matt's comment that the problem here
>> doesn't seem to be in strictness of enforcement, but rather CAs leaving
>> themselves no buffer zone.
>>
>
> The problem here, IMHO, is that the BR requirement was poorly written.
>
> Whatever business advantage there is of giving
>> customers that one last day to get 3-year certs, seems likely not as
>> valuable as the certainty of avoiding giving those customers errors when
>> the certs are used in major browsers.
>>
>
> The certainty?  Hindsight is a wonderful thing.  When I wrote Comodo CA's
> code to enforce the "after 1 March 2018" rule, this "certainty" did no
> occur to me.  I simply read the BR requirement and then implemented code to
> enforce it.


Yeah, I completely get how that would happen. I would just think this is a
good learning opportunity to protect against ambiguously written text by
giving a day's buffer.

Tim's time zone example is another good reason to give that buffer, even if
the BR language made it clear whether it was > or >=. A tangentially
similar comparison would be that in other systems I've built that structure
search results and push notifications around dates, the only safe way to do
it is to assign times as 12:00 UTC, even if that doesn't really accurately
describe the time something happened, so that no matter what time zone
someone is in, they're guaranteed to see it as the same day. It's worth the
imprecision to create consistency.


>
>
> -- Eric
>>
>>
>>
>>> On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti
>>> via dev-security-policy" >> trustwave@lists.mozilla.org on behalf of dev-security-policy@lists.
>>> mozilla.org> wrote:
>>>
>>>  Hello,
>>>
>>>  I'm investigating an issue on behalf of a customer. Our customer
>>> requested a multi-year certificate that was issued on March 1st by
>>> Comodo.
>>>
>>>  Here's the certificate:
>>>  https://crt.sh?id=354042595
>>>
>>>  Validity
>>>  Not Before: Mar  1 00:00:00 2018 GMT
>>>  Not After : May 29 23:59:59 2021 GMT
>>>
>>>  The certificate is currently considered invalid at least by Google
>>> Chrome.
>>>
>>>  It's my understanding that Google Chrome uses a >= comparison, which
>>> effectively means certificates issued on March 1st are already subject to
>>> Ballot 193.
>>>
>>>  However, it looks like the interpretation of Comodo of Ballot 193
>>> here
>>> is based on a > comparison, since the certificate was issued with a 3y
>>> validity.
>>>
>>>  BR 6.3.2 says:
>>>
>>>  > Subscriber Certificates issued after 1 March 2018 MUST have a
>>> Validity Period no greater than 825 days.
>>>  > Subscriber Certificates issued after 1 July 2016 but prior to 1
>>> March 2018 MUST have a Validity Period no greater than 39 months.
>>>
>>>  I'd appreciate some hints about whether a certificate issued on
>>> March
>>> 1st should be considered subject to Ballot 193 or not.
>>>
>>>  Best,
>>>  -- Simone
>>>
>>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>



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

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

[Rob Stradling via dev-security-policy]

On 22/04/18 21:04, Eric Mill via dev-security-policy wrote:

On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


First of all, it's important to distinguish between the BR r
But even if you accept my premise there, then you have to ask "in what
timezone?"  March 1 00:00:00 2018 GMT in North America is February 28.  So
I could see someone making the argument that issuance at that moment in
time is fine if the CA is in North America but it's mis-issuance if the CA
is in Europe, since the requirements don't state that the measurement is
UTC.  This is why I'm not a fan of such precise enforcements of
date-related compliance.  There are a lot of different ways to interpret
dates/times, but none of the readings materially change the net effect of
the rule.  That is, all readings change the max validity period to ~825
days (which itself is subject to debate as to its precise meaning in terms
of seconds) within a day or two of each other.  So, enforcing the date as
Mar 1 as opposed to Mar 2 doesn't seem to add a lot of value and leads to
confusion like this.


I'm just going to double down on Matt's comment that the problem here
doesn't seem to be in strictness of enforcement, but rather CAs leaving
themselves no buffer zone.


The problem here, IMHO, is that the BR requirement was poorly written.


Whatever business advantage there is of giving
customers that one last day to get 3-year certs, seems likely not as
valuable as the certainty of avoiding giving those customers errors when
the certs are used in major browsers.


The certainty?  Hindsight is a wonderful thing.  When I wrote Comodo 
CA's code to enforce the "after 1 March 2018" rule, this "certainty" did 
no occur to me.  I simply read the BR requirement and then implemented 
code to enforce it.



-- Eric




On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti
via dev-security-policy"  wrote:

 Hello,

 I'm investigating an issue on behalf of a customer. Our customer
requested a multi-year certificate that was issued on March 1st by Comodo.

 Here's the certificate:
 https://crt.sh?id=354042595

 Validity
 Not Before: Mar  1 00:00:00 2018 GMT
 Not After : May 29 23:59:59 2021 GMT

 The certificate is currently considered invalid at least by Google
Chrome.

 It's my understanding that Google Chrome uses a >= comparison, which
effectively means certificates issued on March 1st are already subject to
Ballot 193.

 However, it looks like the interpretation of Comodo of Ballot 193 here
is based on a > comparison, since the certificate was issued with a 3y
validity.

 BR 6.3.2 says:

 > Subscriber Certificates issued after 1 March 2018 MUST have a
Validity Period no greater than 825 days.
 > Subscriber Certificates issued after 1 July 2016 but prior to 1
March 2018 MUST have a Validity Period no greater than 39 months.

 I'd appreciate some hints about whether a certificate issued on March
1st should be considered subject to Ballot 193 or not.

 Best,
 -- Simone


--
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: Clarification about Ballot 193 and validity of a certificate issued on March 1st

[Eric Mill via dev-security-policy]

On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> First of all, it's important to distinguish between the BR r
> But even if you accept my premise there, then you have to ask "in what
> timezone?"  March 1 00:00:00 2018 GMT in North America is February 28.  So
> I could see someone making the argument that issuance at that moment in
> time is fine if the CA is in North America but it's mis-issuance if the CA
> is in Europe, since the requirements don't state that the measurement is
> UTC.  This is why I'm not a fan of such precise enforcements of
> date-related compliance.  There are a lot of different ways to interpret
> dates/times, but none of the readings materially change the net effect of
> the rule.  That is, all readings change the max validity period to ~825
> days (which itself is subject to debate as to its precise meaning in terms
> of seconds) within a day or two of each other.  So, enforcing the date as
> Mar 1 as opposed to Mar 2 doesn't seem to add a lot of value and leads to
> confusion like this.
>

I'm just going to double down on Matt's comment that the problem here
doesn't seem to be in strictness of enforcement, but rather CAs leaving
themselves no buffer zone. Whatever business advantage there is of giving
customers that one last day to get 3-year certs, seems likely not as
valuable as the certainty of avoiding giving those customers errors when
the certs are used in major browsers.

-- Eric


>
> On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti
> via dev-security-policy"  trustwave@lists.mozilla.org on behalf of dev-security-policy@lists.
> mozilla.org> wrote:
>
> Hello,
>
> I'm investigating an issue on behalf of a customer. Our customer
> requested a multi-year certificate that was issued on March 1st by Comodo.
>
> Here's the certificate:
> https://crt.sh?id=354042595
>
> Validity
> Not Before: Mar  1 00:00:00 2018 GMT
> Not After : May 29 23:59:59 2021 GMT
>
> The certificate is currently considered invalid at least by Google
> Chrome.
>
> It's my understanding that Google Chrome uses a >= comparison, which
> effectively means certificates issued on March 1st are already subject to
> Ballot 193.
>
> However, it looks like the interpretation of Comodo of Ballot 193 here
> is based on a > comparison, since the certificate was issued with a 3y
> validity.
>
> BR 6.3.2 says:
>
> > Subscriber Certificates issued after 1 March 2018 MUST have a
> Validity Period no greater than 825 days.
> > Subscriber Certificates issued after 1 July 2016 but prior to 1
> March 2018 MUST have a Validity Period no greater than 39 months.
>
> I'd appreciate some hints about whether a certificate issued on March
> 1st should be considered subject to Ballot 193 or not.
>
> Best,
> -- Simone
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://scanmail.trustwave.com/?c=4062=p8zZ2rF2lZEEgQKoVUUviom_
> gMvUa93578dYFlK0UQ=5=https%3a%2f%2flists%2emozilla%
> 2eorg%2flistinfo%2fdev-security-policy
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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