Thank you both. From my standpoint, in this particular example and
Clint's additional context, it could go both ways. At the end of the
day, as long as the language is clear and unambiguous, it can be placed
in any part of the document :)
In order to maintain strict RFC 2119 conformance, the definition of the
Random Value must include the words MUST/SHALL for the 112 bits of
entropy and similarly in other parts of the document. I don't think
anyone can challenge the existing requirement as written, but this is a
technicality that could be fixed throughout the document in a clean-up
ballot. The expectations/results would be exactly the same, but the
output style will be more compatible with RFC 2119.
Dimitris.
On 28/8/2024 11:57 μ.μ., Tim Hollebeek wrote:
That’s a fair point, and thank you for the additional discussion.
There is in fact a large grey area between black and white, as there
usually is.
The reason this one crossed the line into a normative requirement for
me was largely because it defined a Date of Formation, and then was
talking about how that date should be formatted (which requires usage
and context), which I personally think is clearly outside the
boundaries of what a Date of Formation **is**.
The gray area is exactly where you describe, where there can be
disagreements about what is an essential property of a thing, and what
are requirements around a thing. For example, if you had written:
Date of Formation: A ten character string that specifies the date
where a Legal Entity was first recognized by the jurisdiction in which
it was created or formed, in the form of a complete representation of
an extended format calendar date (“YYYY-MM-DD”) in ISO 8601.
Then that clearly defines a thing. I don’t like defining it that way,
but it works. We’re now defining a string, and characterizing its
contents independently of any requirements of how it gets used. The
definition is self-contained and the world is good again. Sort of.
Forward and up,
-Tim
*From:*Clint Wilson <cli...@apple.com>
*Sent:* Wednesday, August 28, 2024 4:25 PM
*To:* Tim Hollebeek <tim.holleb...@digicert.com>
*Cc:* CABforum3 <validation@cabforum.org>; Dimitris Zacharopoulos
(HARICA) <dzach...@harica.gr>
*Subject:* Re: [cabf_validation] Proposed ballot on improving
Registration Number language in EVGs
This is helpful.
To be clear, I agree that normative requirements should be avoided in
definitions, however based on your response to this proposed
definition change, it’s also clear there’s some difference of opinion
on what counts as (or doesn’t) a normative requirement. For example,
what sections of the (T/S/CS)BRs constitute the body of the document?
Is it just Section 1.6 that should be void of normative requirements?
Should normative requirements be pulled out of Section 1 entirely?
Since we don’t introduce RFC 2119 language until Section 1.6.4, does
that mean all uses of those terms in prior sections are incorrect in
some way? How would such a shift impact maintainability of the
document, for example in a scenario where a defined term has its
requirements pulled into a separate section, but then a later usage of
that term doesn’t remember to include these “extra” properties of the
term as used in a specific section?
When I think of a definition, I assume two basic components: the term
being defined and the exact meaning of a word, including the
properties, attributes, or characteristics that term and meaning
encompass. For example, I don’t see the definition of Random Value as
containing normative requirements; rather, it’s describing that in
order for a random value to /be/ a random value, it needs to exhibit
112 bits of entropy. Is there a “MUST” implied in the requirement that
the Reliable Method of Communication be verified by the CA? Should
Wildcard Domain Name not specify the unicode character codes of the
defined characters?
When I think about pulling normative requirements out of definitions,
I’m thinking more of terms like Request Token (because it does clearly
espouse sets of interacting requirements and options) and
Authorization Domain Name (because the concept is complex enough to
warrant expansion in the context of its use rather than solely within
the definition).
My suggestion of including the format in the definition for Date of
Formation was intended to convey that this formatting is an intrinsic
property of the thing being defined. Moving that down into the profile
section is completely acceptable to me. The related suggestion that
this property of the defined term is a requirement that /can't/ be
included in a definition has me confused about the actual expected
outcome to the content, organization, and accessibility of the BRs if
that statement is applied at face value.
Cheers,
-Clint
On Aug 27, 2024, at 9:58 AM, Tim Hollebeek
<tim.holleb...@digicert.com> 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 <cli...@apple.com>
*Sent:*Tuesday, August 27, 2024 9:06 AM
*To:*Tim Hollebeek <tim.holleb...@digicert.com>; CABforum3
<validation@cabforum.org>
*Cc:*Dimitris Zacharopoulos (HARICA) <dzach...@harica.gr>
*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
<validation@cabforum.org> 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 <validation-boun...@cabforum.org>*On Behalf
Of*Dimitris Zacharopoulos (HARICA) via Validation
*Sent:*Friday, August 23, 2024 2:26 AM
*To:*CABforum3 <validation@cabforum.org>
*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<validation@cabforum.org>
<mailto:validation@cabforum.org>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
Validation@cabforum.org <mailto:Validation@cabforum.org>
https://lists.cabforum.org/mailman/listinfo/validation
<https://lists.cabforum.org/mailman/listinfo/validation>
_______________________________________________
Validation mailing list
Validation@cabforum.org
https://lists.cabforum.org/mailman/listinfo/validation
_______________________________________________
Validation mailing list
Validation@cabforum.org
https://lists.cabforum.org/mailman/listinfo/validation
_______________________________________________
Validation mailing list
Validation@cabforum.org
https://lists.cabforum.org/mailman/listinfo/validation
