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

2018-04-22 Thread 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" >>> 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

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

2018-04-22 Thread 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

2018-04-22 Thread 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

2018-04-22 Thread 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&d=p8zZ2rF2lZEEgQKoVUUviom_
> gMvUa93578dYFlK0UQ&s=5&u=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

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

2018-04-20 Thread Matt Palmer via dev-security-policy 
On Fri, Apr 20, 2018 at 01:30:49PM +, Tim Shirley via dev-security-policy 
wrote:
> 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.

Same thing goes the other way, though -- CAs trying to skate too close to
the line to extract maximum "value" out of the old rules also doesn't add a
lot of value, and leads to confusion like this.  If the CA had decided to
not issue certificates over 825 days after, say, Feb 25, there wouldn't have
been any confusion either.  Exact same reasoning applies to bumping up
against the ambiguity of the 825 day limit -- if a CA wants to avoid any
possibility of confusion, they can just be conservative in what they send,
and not issue certificates over, say, 820 days in length.

Live life on the edge, and you're going to fall off now and then.

- Matt

___
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

2018-04-20 Thread sleevi--- via dev-security-policy 
On Friday, April 20, 2018 at 9:31:32 AM UTC-4, Tim Shirley wrote:
> First of all, it's important to distinguish between the BR requirement, which 
> is defined in terms of certificate *issuance* dates, and the value in the 
> "Not Before" field.  I'm guessing the "Not Before" value in this certificate 
> is not the actual issuance timestamp, since it's unlikely it was issued right 
> at the stroke of midnight.  The CA is probably rounding, but we don't know if 
> they're rounding up or down.  But it would only be mis-issuance if the 
> issuance occurred outside of the allowed time window.  There's nothing I can 
> see to show when the certificate was actually issued; it first showed up in 
> CT logs on March 13, so we know it was issued on or before that, but that's 
> all we know for sure about the issuance time.
> 
> So what is the allowed time window according to the BRs?  I'd argue that the 
> intent was that it be >=.  If you read the first bullet's "after" as >, then 
> you have to also read the second bullet's "prior to" as <.  So what rule 
> applies to certificates issued ON March 1, 2018?  Apparently none.  Certainly 
> that wasn't the intent, which is why I interpret the requirement as >=.  That 
> is, the dividing line is the moment in time when we moved from February into 
> March, such that one rule or the other is always in effect.

I agree, it was not the intent, nor is it consistent with the other 
modifications in 193 ( 
https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/ ).

> 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 curious how auditors would view this, since I think this says that's all 
that matters.

>From the client side, we continue to take the most restrictive interpretation 
>that is reasonable, and thus in Chrome, any certificate whose notBefore is >= 
>2018-03-01 00:00:00 UTC and whose difference (in days measured as 60*60*24 
>seconds) is greater than 825 days from the notAfter is rejected.
___
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

2018-04-20 Thread Rob Stradling via dev-security-policy 

On 20/04/18 14:30, Tim Shirley via dev-security-policy wrote:

First of all, it's important to distinguish between the BR requirement, which is defined in terms 
of certificate *issuance* dates, and the value in the "Not Before" field.  I'm guessing 
the "Not Before" value in this certificate is not the actual issuance timestamp, since 
it's unlikely it was issued right at the stroke of midnight.  The CA is probably rounding, but we 
don't know if they're rounding up or down.  But it would only be mis-issuance if the issuance 
occurred outside of the allowed time window.  There's nothing I can see to show when the 
certificate was actually issued; it first showed up in CT logs on March 13, so we know it was 
issued on or before that, but that's all we know for sure about the issuance time.

So what is the allowed time window according to the BRs?  I'd argue that the intent was that it be >=.  If 
you read the first bullet's "after" as >, then you have to also read the second bullet's 
"prior to" as <.  So what rule applies to certificates issued ON March 1, 2018?  Apparently none.  
Certainly that wasn't the intent, which is why I interpret the requirement as >=.


Indeed, I'm sure that wasn't the intent.  However, if the BRs don't say 
what the BRs intend to say, then the fault is with the BRs rather than 
with the CA that adheres to what the BRs actually say.  What the BRs 
actually say is what matters, because that's what auditors will audit 
against.


"after" is not the same thing as "on or after".  "on or after" is used 
elsewhere in the document to me >=, so TBH I think that reading "after" 
as > is the only correct interpretation.


BTW, over in linting-land, we've already had this same discussion...

https://github.com/awslabs/certlint/pull/58

https://github.com/zmap/zlint/pull/195


 That is, the dividing line is the moment in time when we moved from February 
into March, such that one rule or the other is always in effect.

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.

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
 ___
 dev-security-policy mailing list
 dev-security-policy@lists.mozilla.org
 
https://scanmail.trustwave.com/?c=4062&d=p8zZ2rF2lZEEgQKoVUUviom_gMvUa93578dYFlK0UQ&s=5&u=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



--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you

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

2018-04-20 Thread Tim Shirley via dev-security-policy 
First of all, it's important to distinguish between the BR requirement, which 
is defined in terms of certificate *issuance* dates, and the value in the "Not 
Before" field.  I'm guessing the "Not Before" value in this certificate is not 
the actual issuance timestamp, since it's unlikely it was issued right at the 
stroke of midnight.  The CA is probably rounding, but we don't know if they're 
rounding up or down.  But it would only be mis-issuance if the issuance 
occurred outside of the allowed time window.  There's nothing I can see to show 
when the certificate was actually issued; it first showed up in CT logs on 
March 13, so we know it was issued on or before that, but that's all we know 
for sure about the issuance time.

So what is the allowed time window according to the BRs?  I'd argue that the 
intent was that it be >=.  If you read the first bullet's "after" as >, then 
you have to also read the second bullet's "prior to" as <.  So what rule 
applies to certificates issued ON March 1, 2018?  Apparently none.  Certainly 
that wasn't the intent, which is why I interpret the requirement as >=.  That 
is, the dividing line is the moment in time when we moved from February into 
March, such that one rule or the other is always in effect.

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.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

https://scanmail.trustwave.com/?c=4062&d=p8zZ2rF2lZEEgQKoVUUviom_gMvUa93578dYFlK0UQ&s=5&u=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

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

2018-04-19 Thread Simone Carletti via dev-security-policy 
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://lists.mozilla.org/listinfo/dev-security-policy