[cabfcert_policy] Conflict Merging Master into ClarifyCADefinition

[Ben Wilson]

OK - thanks for the clarification.

-----Original Message-----
From: Dimitris Zacharopoulos <jimmy at it.auth.gr> 
Sent: Friday, May 18, 2018 1:07 PM
To: Ben Wilson <ben.wilson at digicert.com>; policyreview at cabforum.org
Cc: Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: Re: Conflict Merging Master into ClarifyCADefinition



On 18/5/2018 7:39 μμ, Ben Wilson wrote:
> Dimitris,
> Github says you want to "merge 6 commits into master from ClarifyCADefinition2".  Shouldn't it be the other way around?
> Thanks,
> Ben

No. ClarifyCADefinition2 includes all commits that advanced since we created the ClarifyCADefinition branch of the master branch. Here is an "illustration" of what happened.

BR v1.5.3 (master)  --->     WG (ClarifyCADefinition)
      |                                               |
      |                                      WG meeting changes
      |                                               | BR v1.5.4 (master)                     |
      |                                               |
      |                                               |
      |                                      WG more meeting changes ...
BR v1.5.7 (master)                     |



So, all this time, the master branch was advancing and so was the ClarifyCADefinition, but these master commits were not merged to the "ClarifyCADefinition" branch which made them out of sync. This created a conflict in 3.2.2.4.1 which had to be resolved manually. Instead of updating the "ClarifyCADefinition" branch, I created a new one that includes all commits from BR 1.5.3 to 1.5.7 AND the commits performed by the WG in the ClarifyCADefinition branch.

The pull request shows the comparison of changes against the existing final version or BR 1.5.7. The request should not be merged. It is here just to display the changes proposed by the WG.


Dimitris.


>
> -----Original Message-----
> From: Dimitris Zacharopoulos <jimmy at it.auth.gr>
> Sent: Friday, May 18, 2018 2:32 AM
> To: Ben Wilson <ben.wilson at digicert.com>; policyreview at cabforum.org
> Cc: Tim Hollebeek <tim.hollebeek at digicert.com>
> Subject: Re: Conflict Merging Master into ClarifyCADefinition
>
> On 17/5/2018 8:01 μμ, Ben Wilson wrote:
>> I got some help taking a look at the GitHUb branch we've been working on.  Before I can merge Master into ClarifyCADefinition, we need to resolve one conflict:
>>
>>
>>
>> ##### 3.2.2.4.1 Validating the Applicant as a Domain Contact
>>
>>
>>
>> Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar. This method may only be used if:
>>
>> 1.            The CA authenticates the Applicant's identity under BR Section 3.2.2.1 and the authority of the Applicant Representative under BR Section 3.2.5, OR
>>
>> 2.            The CA authenticates the Applicant's identity under EV Guidelines Section 11.2 and the agency of the Certificate Approver under EV Guidelines Section 11.8; OR
>>
>> <<<<<<< ClarifyCADefinition
>>
>> 3.            The TSP also operates the Domain Name Registrar, or is an Affiliate of the Registrar, of the Base Domain Name.
>>
>> Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN.  This method is suitable for validating Wildcard Domain Names.
>>
>> =======
>>
>> 3.            The CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.
>>
>> Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. For certificates issued on or after August 1, 2018, this method SHALL NOT be used for validation, and completed validations using this method SHALL NOT be used for the issuance of certificates.
>>
> It's funny that we have to resolve this conflict for one of the 
> to-be-deprecated methods :)
>
> Anyway, I was able to resolve the conflict and created a conflict-free branch (ClarifyCADefinition2) on GitHub. Here is the pull request that displays the proposed changes to the current Baseline Requirements (1.5.7).
>
> https://clicktime.symantec.com/a/1/TQuzgAmQN2I99tyRFr9s_dGR1eLNl7wVotV
> TcjN_OvM=?d=wzom4z4hSPvnH6k_Tkla9H5zi7pXsf6ofZZFElApfn3KPq4H3b8QXJgZW3
> RsZE5g9Yevm9fWQQAOhlktspwKU1ELOWHiqma5dIQHcMP0BeT11sZ5-U2k6hdpVAHN80Zc
> wuzyvNo6qwxfbt4OJurrEweDvIo4WAUKI4E-Hh1zDWWL9b3Ot33_bxqTNIKsJBxkScjR7z
> _R-4-TTma9j_lI-KV3p_sgpkilMNdgwmqVz_yWSCD7sYEEEeHUAYyNbc_FdFp4-vdCCV2u
> uZnbd-raS_QzcXcybInmyPsCZgCeAWvaCGNWT7WbOfo6NLyduCqD74E9tkIb5JJ2Yq-T9N
> nT8eA4SEH-jxVfHtA5AWuqIKcx8SqIzkAP0ap2SN6bAmIEZZrLwDB5ULqouA%3D%3D&u=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fpull%2F95%2Ffiles%23diff-7f6d14a20e7f3beb696b45e1bf8196f2
>
>
> Dimitris.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4934 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/policyreview/attachments/20180518/67a0304a/attachment-0001.p7s>