All, In reading through the logic of PKIX base profile related to Name Constraints [1], it appears that the relationship between the GeneralName of the constraint subtrees and the GeneralName of the SAN being constrained is based on correlating the GeneralName tag and the OtherName type-id between the two. But I don't see any actual requirement that this is the case, just an implication based on how the statements in [1] are phrased and the scoping statement:
The syntax and semantics for name constraints for otherName, ediPartyName, and registeredID are not defined by this specification, however, syntax and semantics for name constraints for other name forms may be specified in other documents. So is the correlation of OtherName type-id necessarily the case, or is it more flexible? Meaning, could I define an Other Name Form so that NameConstraints has OtherName type-id _OID1_ that actually constrains a SAN with OtherName type-id _OID2_? Or is that kind of cross-constraining just going to run into implementation hurdles and not worth trying? The reason I bring this up is that there is similar logic for c509 certificates [2] using COSE encoding but not a strong model of how the "C509 General Names Registry" are supposed to relate beween GeneralName used in SAN or similar and when used in Name Constraints. The Name Constraints values typically involve patterns, either glob/wildcard or in the case of ipAddress a CIDR block rather than a single address. There is a proposal for a bundle EID Pattern [3] that seems like it would have utility within a Name Constraints but can that constraint apply to a single EID value (id-on-bundleEID; 1.3.6.1.5.5.7.8.11), but that would mean a Name Constraints with one type-id OID limiting the contents of a SAN value with a different type-id OID. If the OtherName type-id must be equal then the draft [2] might need to be more clear about some of its General Names Registry uses (i.e. do they apply or not apply to Name Constraints). Thanks for any feedback from those with more visibility into PKIX systems/tools. Brian S. [1] https://www.rfc-editor.org/rfc/rfc5280.html#section-4.2.1.10 [2] https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-11.html [3] https://www.ietf.org/archive/id/draft-sipos-dtn-eid-pattern-02.html
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
