[cabfpub] Public Digest, Vol 57, Issue 110

Virginia Fournier vfournier at apple.com
Thu Jan 12 11:33:24 MST 2017


Hi Jeremy,

"I don't think joining is prohibited provided she isn't the PAG chair:"

VMF:  I believe this is correct.  In other SDOs, the excluders often participate in the related PAGs.


Section 7.3.1 is guiding:

"The PAG will be convened by a Chair who shall be elected by the PAG and who
must not be affiliated with the company owning the Essential Claim that is
the subject of the PAG."



From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Doug Beattie
via Public
Sent: Thursday, January 12, 2017 5:37 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: Doug Beattie <doug.beattie at globalsign.com>;
CA/Browser at p3plcabfweb01.prod.phx3.secureserver.net; Public Discussion List
<public at cabforum.org>
Subject: Re: [cabfpub] Volunteers needed to serve on a Patent Advisory Group
(PAG) for Ballot 182



Kirk,



Carolyn Oldenburg of GlobalSign would like to volunteer to be on the PAG
assuming there is not a conflict because we filed an exclusion notice.


Doug



From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Kirk Hall via
Public
Sent: Tuesday, January 3, 2017 4:49 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org
<mailto:public at cabforum.org> >
Cc: Kirk Hall <Kirk.Hall at entrustdatacard.com
<mailto:Kirk.Hall at entrustdatacard.com> >
Subject: [cabfpub] Volunteers needed to serve on a Patent Advisory Group
(PAG) for Ballot 182



Because there were Exclusion Notices filed for Ballot 182 during the Review
Period, we must now form a Patent Advisory Group to review the Exclusion
Notices.  Once convened, the PAG will elect its own Chair, who can't be
affiliated with a company that filed an Essential Claim.



Who will volunteer to serve on the PAG?  



Our IPR Policy provides as follows:



7. Exception Handling



7.1. PAG Formation



In the event a patent has been disclosed that may contain an Essential
Claim, but such Essential Claim is not available under CAB Forum RF
Licensing, a Patent Advisory Group (PAG) will be launched to resolve the
conflict. The PAG is an ad-hoc group constituted specifically in relation to
the Final Guideline or Final Maintenance Guideline containing the conflict.
A PAG may also be formed without such a disclosure if a PAG could help avoid
anticipated patent problems.



7.3. PAG Procedures



7.3.1. PAG Formation Timing



The PAG will be convened by a Chair who shall be elected by the PAG and who
must not be affiliated with the company owning the Essential Claim that is
the subject of the PAG. The timing for convening the PAG is at the
discretion of the Chair. In some cases, convening a PAG before a specific
patent disclosure is made may be useful. In other cases, it may be that the
PAG can better resolve the licensing problems when the specification is at
the Review Period level.



7.3.2. Possible PAG Conclusions



After appropriate consultation, the PAG may conclude:



a. The initial concern has been resolved, enabling the work on the Guideline
to continue.

b. The CAB Forum should be instructed to consider designing around the
identified claims.

c. The PAG should seek further information and evaluation, including and not
limited to evaluation of the patents in question or the terms under which
CAB Forum RF licensing requirements may be met.

d. The project relating to the Draft Guideline in question should be
terminated.

e. The Final Guideline or Final Maintenance Guideline should be rescinded.

f. Alternative licensing terms should be considered.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170112/4098cb9e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170112/4098cb9e/attachment-0001.bin>

------------------------------

Message: 2
Date: Thu, 12 Jan 2017 17:51:45 +0000
From: Gervase Markham <gerv at mozilla.org>
To: CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)
Message-ID: <0ea7410e-fdcd-9174-a24d-e2f538a36d4a at mozilla.org>
Content-Type: text/plain; charset=utf-8

Here's v4. I've decided to leave the email situation unchanged for now,
in the name of getting the SSL situation put to bed. We can address it
in a different discussion.

This is the same as v3 except it allows the issuance of SHA-1
intermediates to add EKUs so that they can be used in chains meeting the
other requirements (a fix for a problem Bruce pointed out).

<quote>
CAs may only sign SHA-1 hashes over end-entity certificates which chain
up to roots in Mozilla's program if all the following are true:

1) The end-entity certificate:
* is not within the scope of the Baseline Requirements;
* contains an EKU extension which does not contain either of the id-kp-
 serverAuth or anyExtendedKeyUsage key purposes;
* has at least 64 bits of entropy from a CSPRNG in the serial number.

2) The issuing intermediate:
* contains an EKU extension which does not contain either of the id-kp-
 serverAuth or anyExtendedKeyUsage key purposes;
* has a pathlen:0 constraint.

CAs may only sign SHA-1 hashes over issuing intermediates which chain
up to roots in Mozilla's program if the certificate to be signed is a
duplicate of an existing SHA-1 intermediate certificate with the only
change being the addition of an EKU to meet the requirements outlined above.

CAs may only sign SHA-1 hashes over OCSP responses if the signing
certificate contains an EKU extension which contains only the
id-kp-ocspSigning EKU.

CAs may only sign SHA-1 hashes over CRLs for roots and intermediates
which have issued SHA-1 certificates.

CAs may not sign SHA-1 hashes over other data, including CT
pre-certificates.
</quote>

Gerv


------------------------------

Message: 3
Date: Thu, 12 Jan 2017 18:17:36 +0000
From: Jeremy Rowley <jeremy.rowley at digicert.com>
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)
Message-ID: <b5be2e04f3fd4982ac00d95ebf23d35f at EX2.corp.digicert.com>
Content-Type: text/plain; charset="us-ascii"

Hey Gerv - when dos this policy take effect? Or is this being proposed for
the next Mozilla policy update.

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: Thursday, January 12, 2017 10:52 AM
To: CABFPub <public at cabforum.org>
Cc: Gervase Markham <gerv at mozilla.org>
Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

Here's v4. I've decided to leave the email situation unchanged for now, in
the name of getting the SSL situation put to bed. We can address it in a
different discussion.

This is the same as v3 except it allows the issuance of SHA-1 intermediates
to add EKUs so that they can be used in chains meeting the other
requirements (a fix for a problem Bruce pointed out).

<quote>
CAs may only sign SHA-1 hashes over end-entity certificates which chain up
to roots in Mozilla's program if all the following are true:

1) The end-entity certificate:
* is not within the scope of the Baseline Requirements;
* contains an EKU extension which does not contain either of the id-kp-
 serverAuth or anyExtendedKeyUsage key purposes;
* has at least 64 bits of entropy from a CSPRNG in the serial number.

2) The issuing intermediate:
* contains an EKU extension which does not contain either of the id-kp-
 serverAuth or anyExtendedKeyUsage key purposes;
* has a pathlen:0 constraint.

CAs may only sign SHA-1 hashes over issuing intermediates which chain up to
roots in Mozilla's program if the certificate to be signed is a duplicate of
an existing SHA-1 intermediate certificate with the only change being the
addition of an EKU to meet the requirements outlined above.

CAs may only sign SHA-1 hashes over OCSP responses if the signing
certificate contains an EKU extension which contains only the
id-kp-ocspSigning EKU.

CAs may only sign SHA-1 hashes over CRLs for roots and intermediates which
have issued SHA-1 certificates.

CAs may not sign SHA-1 hashes over other data, including CT
pre-certificates.
</quote>

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170112/0532c570/attachment.bin>

------------------------------

Subject: Digest Footer

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public


------------------------------

End of Public Digest, Vol 57, Issue 110
***************************************



More information about the Public mailing list