Repository navigation
Labels
enhancementNew feature or requestNew feature or requestintegrationRelated to integration of SSVC into another framework or systemRelated to integration of SSVC into another framework or systemintegration/blockerSomething that is blocking integration with another framework or systemSomething that is blocking integration with another framework or systemtech/backendBack-end tools, code, infrastructureBack-end tools, code, infrastructuretech/dataData implementation (content of /data, data object instances, etc.)Data implementation (content of /data, data object instances, etc.)
Milestone
Description
(Comments from @tschmidtb51)
Given my thought process over time and during that review: I'm now full convinced that we should differentiate between
languageandx-nameas this improves parsing and validation significantly. Therefore, I suggest - in addition with some other improvements:
- all lower case except for BCP 47
- allow for fragment parts also in unregistered namespaces
- correct extentions in BCP 47
- explicitly state reverse DNS (except for the length rule - that need to be in the regex)
!!! info "ABNF Notation"
```abnf
namespace = base-ns [extensions]
; Overall namespace must be 3–1000 characters
; (Enforced via regex length lookahead)
base-ns = x-base / std-base
x-base = "x_" x-name
std-base = ns-core
; ns-core starts with a lowercase letter and may have '.' or '-' separators.
; Consecutive '.' or '-' are not allowed.
ns-core = LOWER ALNUMLOW *("." / "-" 1*ALNUMLOW)
x-name = reverse-dns [ "#" fragment-seg ]
; reverse-dns provides an specification for a reverse DNS name
; can't be longer than 253 characters
reverse-dns = label 1*("." label)
; Each label must be between 1 and 63 characters long
label = ALNUMLOW [ *61(ALNUMLOWDASH) ALNUMLOW ]
fragment-seg = 1*ALNUMLOW *( ("." / "-") 1*ALNUMLOW )
extensions = lang-ext [ 1*("/" ext-seg) ]
; Language extension: either / (empty language extension)
; or /<bcp47>/ (BCP-47 language code)
lang-ext = "/" / ( "/" bcp47 )
; Extension segment between slashes.
; - Must start with ALPHA
; - May have '.' or '-' separators
; - Optional '#' section, at most one per segment
; - No consecutive '.' or '-'
ext-seg = bcp47 / "." x-name
; BCP-47 tag (based on the regex expansion)
bcp47 = ( 2*3ALPHA
[ "-" 3ALPHA *2( "-" 3ALPHA ) ]
/ 4*8ALPHA )
[ "-" 4ALPHA ]
[ "-" ( 2ALPHA / 3DIGIT ) ]
* ( "-" ( 5*8ALNUM / DIGIT 3ALNUM ) )
* ( "-" singleton 1*("-" (2*83ALNUM)))
[ "-" "x" 1*( "-" 1*8ALNUM ) ]
/ "x" 1*( "-" 1*8ALNUM )
/ "i-default"
/ "i-mingo"
; Single alphanumerics
; "x" reserved for private use
singleton = DIGIT ; 0 - 9
/ %x41-57 ; A - W
/ %x59-5A ; Y - Z
/ %x61-77 ; a - w
/ %x79-7A ; y - z
; Character sets
LOWER = %x61-7A ; a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
ALNUM = ALPHA / DIGIT
ALNUMLOW = LOWER / DIGIT
SPECIALCHAR = DOT / DASH
DOT = %x2E; .
DASH = %x2D ; -
ALNUMLOWSC = ALNUMLOW / SPECIALCHAR
ALNUMLOWDASH = ALNUMLOW / DASH
; Constraints:
; - No consecutive "." or "-" in ns-core or ext-seg; exception in label
; - Each ext-seg can contain at most one "#".
; - Overall namespace is 3–1000 chars.
```
The question whether
a-a-----aora---ais valid as label is still open. Based on the RFC 1035, I would say yes. For the latter one,digcomplains about some IDNA2008...
@ahouseholder @sei-vsarvepalli: I hope I corrected all mistakes I discovered earlier but please double check.
Originally posted by @tschmidtb51 in #821 (comment)
Metadata
Metadata
Labels
enhancementNew feature or requestNew feature or requestintegrationRelated to integration of SSVC into another framework or systemRelated to integration of SSVC into another framework or systemintegration/blockerSomething that is blocking integration with another framework or systemSomething that is blocking integration with another framework or systemtech/backendBack-end tools, code, infrastructureBack-end tools, code, infrastructuretech/dataData implementation (content of /data, data object instances, etc.)Data implementation (content of /data, data object instances, etc.)
Activity
tschmidtb51 commentedon Aug 8, 2025
Based on our discussion today:
Notable changes:
reg-base) are allow to have fragmentsx-base) are required to have fragmentsext-segstschmidtb51 commentedon Aug 8, 2025
Valid Examples and their meaning
ssvc//.de.bund.bsi$de-DEssvc//.de.bund.bsi#ref-arch-1/de-DEref-arch-1model which is originally written in Englishssvc//.de.bund.bsi#ref-arch-2$de-DEref-arch-2model which is originally written in Germanssvc//.de.bund.bsi#ref-arch-2$de-DE/en-GBref-arch-2model which is originally written in Germannist#800-30x_gov.nist#800-30/de-DEx_gov.nist#800-30//.de.bund.bsi$de-DEInvalid Examples
ssvc$de-DEanssi#800-30$fr-FRx_gov.nist#800-30$de-DEx_gov.nist#800-30/.de.bund.bsi$de-DEtschmidtb51 commentedon Aug 8, 2025
@ahouseholder Small gap with
ssvc$de-DE: How do we communicate, that a model is in a certain language only (aka its "base" language)? I think, we currently assume that all are inen-US. Do we actually care? (Currently, I would tend to say "No".)ahouseholder commentedon Aug 8, 2025
I would expect
foo/de-DE,foo#bar/de-DEorx_foo#bar/de-DEto be sufficient for this.My preference is to keep it simple and not add more complexity if we can avoid it though.
But I could also see an argument for
fooen-USfoo$de-DEfoo#bar$de-DEx_foo#bar$de-DEen-USbeing reasonable if there's sufficient need for it. I'm leaning toward YAGNI on this one, but open to discussion.
tschmidtb51 commentedon Aug 12, 2025
Sounds good to me.
Let's leave it as is and not allow base language as separate indicator for now.
tschmidtb51 commentedon Aug 12, 2025
@ahouseholder We are good to start with the PR here, correct?
2 remaining items
bernhardreiter commentedon Aug 13, 2025
(documenting first steps, will analyse it further)
Gave #858 (comment) a spin with
after:
; Overall namespace must be 3–1000 charactersrunning
abnf-to-regexp --format single-regexp -i s1.abnfcomplains about:bernhardreiter commentedon Aug 14, 2025
(progress to understand one error message):
For
abnf-to-regexpto work, the file must be 7-bit and the lines must be terminated by CRLF.That is twice an unicode EN DASH character, encoded as UTF-8:
0xe2.80.93in a comment.bernhardreiter commentedon Aug 14, 2025
Here is a version of the above ABNF file that can be parsed by abnf-to-regexp and the resulting output.
(@tschmidtb51 has contracted me and my colleagues to assist with this issue. I will see for the next steps later.)
Here is the diff, which removes the unicode characters, and three whitespaces which are not allowed:
Working filename
s2.abnf, to be saved with CRLF line terminations, thoughabnf-to-regexpalso works on it with LF line terminations on GNU/Linux:running
abnf-to-regexp --format python-nested -i s2.abnf:running
abnf-to-regexp --format single-regexp -i s2.abnf:tschmidtb51 commentedon Aug 14, 2025
@bernhardreiter Just saw that there is a mistake in the original file:
83ALNUMmust be8ALNUMaccording to BCP47tschmidtb51 commentedon Aug 14, 2025
@bernhardreiter Updated your raw version:
bernhardreiter commentedon Aug 15, 2025
based on a branch with fixed testing framework (having applied #881), https://github.com/Intevation/certcc-SSVC/commit/574f4c8bd878a798156deeb1cfd66456dc351009 adds the pattern from above to the testsuite as preparation to resolve this issue.
So a failed test is expected, here is the message:
(some line endings added for readability)
bernhardreiter commentedon Aug 15, 2025
The latest ABNF here (working name
s3.abnf) from above mandates a#forx_basetype namespaces:this leads to
x_com.yahooincbeing invalid and number of testcases have to be changed.It is intentional as #858 (comment) has:
tschmidtb51 commentedon Aug 15, 2025
Yes. As we changed the structure (based on the decisions conveyed by the ABNF) some test cases will be invalid and need to be adapted.
bernhardreiter commentedon Aug 15, 2025
One of the valid examples from above (#858 (comment)) is
but this does not validate from the ABNF, because a single
/is the emptylang-extthen only a second slash can follow before a translation.@tschmidtb51 Am I correct and the example should be corrected to
x_gov.nist#800-30//.de.bund.bsi$de-DE(with the slash added)?(I'll continue working with that assumption.)
bernhardreiter commentedon Aug 15, 2025
In addition to changes here, the documentation in https://github.com/CERTCC/SSVC/blob/main/docs/reference/code/namespaces.md will need further updates. I will replace
x_example.testwithx_org.example#bar, but it is not entirely clear to me how the surrounding text should be updated with the changes that come with this issue.bernhardreiter commentedon Aug 15, 2025
New merge requests #882 will resolve the issue, see detailed remarks there.
tschmidtb51 commentedon Aug 15, 2025
Yes. I updated that above.