Hi Ben,

Thanks for your response, it was very helpful.

> The data in the field you reference previously read (last year until it
was updated)  "*.gov.tr, *.k12.tr, *.pol.tr, *.mil.tr, *.tsk.tr, *.kep.tr,*.
bel.tr,*.edu.tr, *.org.tr" - so it was comma-delimited.

Great, thanks. Out of curiosity is there a way for external folks to look
at historical data to answer this kind of question themselves or is that
magic you're doing behind the scenes with access to the backing Salesforce
instance?

> The answer to your second question is "yes" - the wildcard character is
meant to express the permitted subtree, but we could remove it if there
were a good reason.  If you have any suggestions, we might be able to
modify how these are expressed in this field in the CCADB. (In NSS, they
don't have the wildcard character.)

Thanks for confirming.

I would be in favour of dropping the leading `*` since the 5280 encoding of
the dNSName general name used as the permitted subtree base won't have it
present in order to be able to perform the name constraint satisfaction
test that involves prepending zero or more labels to the left-hand side.
Like in NSS I've been removing it as part of building the constraints
extension from the CSV data.

> In answer to your third question about excluded subtrees, that is not
something that we have considered at this time.

Understood.

Thanks again,

- Daniel


On Thu, Aug 10, 2023 at 4:25 PM Ben Wilson <[email protected]> wrote:

> Greetings Daniel,
>
> The data in the field you reference previously read (last year until it
> was updated)  "*.gov.tr, *.k12.tr, *.pol.tr, *.mil.tr, *.tsk.tr, *.kep.tr
> ,*.bel.tr,*.edu.tr, *.org.tr" - so it was comma-delimited.
>
> The answer to your second question is "yes" - the wildcard character is
> meant to express the permitted subtree, but we could remove it if there
> were a good reason.  If you have any suggestions, we might be able to
> modify how these are expressed in this field in the CCADB. (In NSS, they
> don't have the wildcard character.)
>
> In answer to your third question about excluded subtrees, that is not
> something that we have considered at this time. I don't foresee it becoming
> a new column in the report or modifying interpretation of the current CCADB
> field.  I am not sure whether that excluded-subtrees logic is in the code.
> I could investigate that further if needed.
>
> Please let us know if we can provide further clarification.
>
> Thanks,
> Ben Wilson
> Mozilla Root Program
>
> On Tue, Aug 8, 2023 at 2:42 PM Daniel McCarney <[email protected]>
> wrote:
>
>> Hi folks,
>>
>> The "IncludedCACertificateReportPEMCSV"
>> <https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportPEMCSV>
>>  report
>> available from CCADB contains a column labelled "Mozilla Applied
>> Constraints".
>>
>> Presently the only row with a value in that column is the CA certificate
>> with common name "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1"
>> (fingerprint:
>> 46EDC3689046D53A453FB3104AB80DCAEC658B2660EA1629DD7E867990648716), which
>> has the Mozilla Applied Constraints column value of "*.tr".
>>
>> I'm interested in creating automation that can build a set of trust
>> anchors from the CSV content that would include imposed name constraints,
>> but would appreciate input on my assumptions about the format of this
>> column:
>>
>> * Is it fair to assume this field will only express a single value? If
>> multiple values are possible, would they be a JSON encoded array or use
>> some other delimiter?
>> * Is it fair to assume a value like "*.tr" is intended to convey an RFC
>> 5280 name constraint extension carrying a permitted subtree with a base
>> dNSName GeneralName with the value ".tr", and that future updates would
>> follow the same pattern (e.g. using a wildcard character)?
>> * If the above interpretation is correct, is there a potential that
>> excluded subtrees would be expressed somehow in the future? Would that be a
>> new column, or somehow encoded into the value of the existing column?
>>
>> Thanks!
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "CCADB Public" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/a/ccadb.org/d/msgid/public/9ceb3a8d-6257-4deb-91ef-5e82c8e7daf1n%40ccadb.org
>> <https://groups.google.com/a/ccadb.org/d/msgid/public/9ceb3a8d-6257-4deb-91ef-5e82c8e7daf1n%40ccadb.org?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CAPSmj0Szqc8Uc_x-sSD2FD3R0qGmfoMYck1DMcbFm2dYbQswpg%40mail.gmail.com.

Reply via email to