FWIW I agree with Tim on this. Historically we've tried to move
requirements away from definitions and into the main text, as Tim wrote.
Effectively it produces the same result but it is more consistently
aligned with the RFC 2119 language.
If there are more definitions that include normative requirements, we
could highlight them in a GitHub issue and add them in a clean-up ballot
that will ensure consistency in this practice.
Thanks,
Dimitris.
On 27/8/2024 7:58 μ.μ., Tim Hollebeek wrote:
My opinion is that all requirements need to be stated in RFC 2119
language and be present in the body of the document in order to be
treated as normative requirements. That should be an uncontroversial
view. I suspect our auditor friends have a similar view. I don’t think
it’s a particularly hard line or strict view, it’s just what’s
necessary to prevent ambiguity as to what the requirements are.
I would be fine with once in the section. Something along the lines of
“The Date of Formation MUST be formatted according to the complete
representation of an extended format calendar date in ISO 8601 (i.e.
YYYY-MM-DD; e.g. 0001-01-01).”
-Tim
*From:*Clint Wilson <[email protected]>
*Sent:* Tuesday, August 27, 2024 9:06 AM
*To:* Tim Hollebeek <[email protected]>; CABforum3
<[email protected]>
*Cc:* Dimitris Zacharopoulos (HARICA) <[email protected]>
*Subject:* Re: [cabf_validation] Proposed ballot on improving
Registration Number language in EVGs
Hi Tim,
I think including the format of this specific date type in the
definition is totally reasonable, given that it’s not applicable to
any other date types and so can very much exist intrinsically as part
of the definition. That is, I don’t agree with the seemingly hard line
you’re drawing in your statement — and, even moreso, I don’t believe
such a statement is backed by consensus within the Forum so I also
don’t want it construed as more than your opinion, as indeed is my
above statement that it can be part of the definition.
All that said, I do agree putting it in-line in the EVGs would work
just fine too. Are you then imagining we would repeat this format
requirement alongside each of the four times the term is used in
7.1.4.2.5 or just state it once somewhere in that section? Do you have
some example text you can provide to show what you’re proposing as an
alternative approach?
Thank you,
-Clint
On Aug 26, 2024, at 10:32 AM, Tim Hollebeek via Validation
<[email protected]> wrote:
This is a requirement, and any requirements around how dates
should be formatted need to be stated as such in the appropriate
profile section. It MUST NOT be stated in the definition.
-Tim
*From:*Validation <[email protected]>*On Behalf
Of*Dimitris Zacharopoulos (HARICA) via Validation
*Sent:*Friday, August 23, 2024 2:26 AM
*To:*CABforum3 <[email protected]>
*Subject:*Re: [cabf_validation] Proposed ballot on improving
Registration Number language in EVGs
On 16/8/2024 2:53 π.μ., Clint Wilson via Validation wrote:
Hi Corey,
Overall this seems like a good improvement to clarity of the
current expectations related to these sections of the EVGs,
reflecting the predominant approach to populating the
subject:serialNumber field for EV TLS certificates. I do think
it would be valuable to standardize on a date format
(admittedly somewhat because it feels like a missed
opportunity to not do so). What about something like modifying
the newly added definition:
**Date of Formation**: The date on which a Legal Entity is
first recognized by the jurisdiction in which it was
created or formed. The date is formatted according to the
complete representation of an extended format calendar
date in ISO 8601 (i.e. YYYY-MM-DD; e.g. 0001-01-01).
Hi Clint,
I'm in favor of examples where they help avoid unintended
mistakes, so I would support adding something like "e.g.
2000-12-31" to make it abundantly clear where the month and day is
supposed to be represented.
Thanks,
Dimitris.
The parenthetical is probably too much, but you get the idea.
And then the three instances of "in any one of the common date
formats” could just be deleted.
Cheers,
-Clint
On Aug 9, 2024, at 8:55 AM, Corey Bonnell via
Validation<[email protected]>
<mailto:[email protected]>wrote:
Hello,
Some time ago, I presented [1] a ballot proposal on
improving the requirements for the Registration Number
value in the EVGs. Here is the current
proposal:https://github.com/cabforum/servercert/compare/main...CBonnell:servercert:govt-entity-serial-number
<https://github.com/cabforum/servercert/compare/main...CBonnell:servercert:govt-entity-serial-number>.
On the call where the proposal was presented, there was a
desire to explore standardizing date formats for the Date
of Formation. Is this something that we would like to see
added to the ballot? For the sake of minimizing scope of
the ballot, I’m in favor of moving forward without such a
requirement, but will certainly be happy to incorporate if
there are strong feelings that such a requirement should
be added in this ballot.
Thanks,
Corey
[1]https://lists.cabforum.org/pipermail/validation/2024-July/001997.html
<https://lists.cabforum.org/pipermail/validation/2024-July/001997.html>
_______________________________________________
Validation mailing list
[email protected] <mailto:[email protected]>
https://lists.cabforum.org/mailman/listinfo/validation
<https://lists.cabforum.org/mailman/listinfo/validation>
_______________________________________________
Validation mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/validation
_______________________________________________
Validation mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/validation
_______________________________________________
Validation mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/validation
