Questions about mozilla applied constraints

[Daniel McCarney]

Hi folks,

The "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!

[Ben Wilson]

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

--
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 public+un...@ccadb.org.
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.

[Daniel McCarney]

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