[Servercert-wg] Voting Begins: Ballot SC24 V2: Fall Cleanup

Enrique Alvarez ealvarez at firmaprofesional.com
Mon Nov 11 01:45:25 MST 2019


Firmaprofesional votes YES on ballot SC24 V2

Thanks!

*Enrique Álvarez Sendino*

Compliance Officer

+34 686 064 158



*Barcelona  *Edif. ESADECREAPOLIS - Av. Torre Blanca 57, Local 3B6 - 08173
Sant Cugat del Vallès / +34 934 774 245

*Madrid  *C/ Velázquez 59, 1º Ctro-Izda. - 28001 Madrid / +34 915 762 181



*www.firmaprofesional.com <http://www.firmaprofesional.com/>*


El contenido de este correo electrónico y de sus anexos es confidencial. Si
usted recibe este mensaje por error, debe saber que está prohibido hacer
uso, divulgación y/o copia del mismo. En tal caso le agradeceríamos que
advierta de inmediato a su remitente y que proceda a destruir el mensaje.



Le informamos que, cumpliendo la normativa en materia de protección de
datos, FIRMAPROFESIONAL tratará sus datos con la finalidad de garantizar
las relaciones con la empresa, entidad u organización a la que usted
representa o en la que trabaja y por el período que dure dicha relación. Podrá
ejercer sus derechos de acceso, rectificación, supresión, limitación,
portabilidad y oposición al tratamiento ante el Responsable:
FIRMAPROFESIONAL, S.A., Av. Torre Blanca, 57, local 3B6 (Edificio
ESADECREAPOLIS), 08173 Sant Cugat del Vallès (Barcelona), o bien mediante
correo electrónico a: rgpd at firmaprofesional.com, en cualquier caso
adjuntando una copia de su D.N.I. o documento equivalente. Asimismo, podrá
formular reclamaciones ante la Agencia Española de Protección de Datos. Para
más información puede consultar nuestra política de privacidad
<https://www.firmaprofesional.com/esp/aviso-legal>.


El mar., 5 nov. 2019 a las 6:01, Wayne Thayer via Servercert-wg (<
servercert-wg at cabforum.org>) escribió:

> Ballot SC24: Fall Cleanup v2
>
> Purpose of Ballot:
>
> This ballot proposes to correct a number of minor errata that have been
> discovered in the BRs and EVGLs. The specific list of changes and
> motivations is as follows:
>
> To the BRs:
>
>    -
>
>    Remove overall ‘1 July 2012’ effective date for the BRs
>    -
>
>    Correct the authorized port descriptive label (http -> https)
>    -
>
>    Correct a few typos (contract -> contact, assigns -> assignees)
>    -
>
>    Clarify the Request Token should be documented in the CP/CPS (or a
>    document referenced from the CP/CPS)
>    -
>
>    Move the construction examples of a Request Token to the definition of
>    a Request Token
>    -
>
>    Remove the definition of Test Certificate, as it is no longer used in
>    the BRs
>    -
>
>    Correct some of our acronyms
>    -
>
>    Remove effective dates that are in the past
>    -
>
>    Remove validation methods that are no longer permitted
>    -
>
>       Note: This also involves typographical changes to section 3.2.2.4;
>       the sections were inconsistent in their use of boiler plate, and so this
>       simply aligned the formatting and line spacing, since this ballot is for
>       changes that are non-normative in impact
>       -
>
>    Correct some unnecessarily gendered language to be gender-neutral
>    -
>
>    Clarify that the usable OIDs in a certificatePolicies are what the CA
>    documents, and not simply restricted to a CA's own OID arc.
>    -
>
>       This is to make it clear that it's fine to use the CABF-defined
>       OIDs for DV/OV/IV/EV
>       -
>
>    Add the OID for organizationalUnitName, matching the rest of the
>    Subscriber DN documentation
>    -
>
>    Clean up the algorithm requirements
>    -
>
>       Section 6.1.5 is rewritten to reflect what is permitted. This is
>       especially important to clarify the requirements are about when it's
>       issued, and not simply the validity period expressed in the certificate.
>       -
>
>       Section 7.1.3 is partially rewritten. The MUST NOT is still kept,
>       even though Section 6.1.5 clearly omits it, in order to avoid any ambiguity.
>       -
>
>       It also removes the now-expired grandfathering for OCSP responders.
>       -
>
>    Referring to “RFC5280” vs “RFC 5280”
>
> To the EVGs:
>
>    -
>
>    Unify the references to BRs to consistently say Baseline Requirements
>
>
>
> The following motion has been proposed by Wayne Thayer of Mozilla and
> endorsed by Ryan Sleevi of Google and Jacob Hoffman-Andrews of Let’s
> Encrypt.
>
>
> -- MOTION BEGINS --
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as defined in the following
> redline, based on Version 1.6.6:
>
>
> https://github.com/cabforum/documents/compare/master@%7B10-25-19%7D...sleevi:2019-07-Cleanups@%7B10-25-19%7D
>
> This ballot modifies the “Guidelines for the Issuance and Management of
> Extended Validation Certificates” as defined in the following redline,
> based on Version 1.7.0:
>
>
> https://github.com/cabforum/documents/compare/master@%7B10-25-19%7D...sleevi:2019-07-Cleanups@%7B10-25-19%7D
>
> -- MOTION ENDS --
>
> This ballot proposes Final Maintenance Guidelines.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 21-October 2019 18:00 UTC
>
> End Time: 05-November 2019 05:00 UTC
>
>
> Vote for approval (7 days)
>
> Start Time: 05-November 2019 05:00 UTC
>
> End Time: 12-November 2019 05:00 UTC
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191111/c64203b4/attachment-0001.html>


More information about the Servercert-wg mailing list