On Fri, Nov 11, 2016 at 4:42 AM, Gervase Markham <[email protected]> wrote: > Hi Peter, > > On 11/11/16 01:42, Peter Bowen wrote: >> Given that there is a lack of clarity on when the CABF BRs apply, and >> that applicability of the BRs is outside the scope of the BRs, I >> propose the following text to clarify and help CAs understand the >> expectations of operating a publicly trusted CA. > > This is helpful, thank you. Is it your proposal that this, or something > like it, would be incorporated into Mozilla's root store policy as a > "Scope" section or similar name?
Yes. > The following issues with our current policy may be relevant: > https://github.com/mozilla/pkipolicy/issues/27 > https://github.com/mozilla/pkipolicy/issues/5 I think any increase in requirements needs to be carefully considered given that many Root CAs are included in multiple browser trust stores. For example, forbidding DSA would impact all browsers. >> The WebPKI is based on certificate as described in RFC 5280. It is >> inspired by ITU-T X.500 series standards but does not always comply >> with the X.500 standards. In particular, WebPKI acknowledges and >> accepts that the Directory Information Tree does not exist and >> therefore focused on properties of subjects rather than their >> relationships. > > I sort of think I know what you mean here, but could you expand this > last part? The attributes included in distinguished names are properties of a subject and may vary based what the CA has verified. It should not be assumed that it is possible to build a tree based on the properties; there might be completely disjoint sets of properties in the subjects of certificates. >> Therefore Distinguished Names, while being Sequences >> of Relative Distinguished Names (RDNs), are treated as an unordered >> Set of RDNs and different natural persons or legal entities may have >> the same Distinguished Name if the described properties of the persons >> or entities are the same. > > This is true, but is it important enough to be put here? What practical > affect does it have to acknowledge this truth? This is a point of confusion for many CAs attempting to join the WebPKI. They usage of the DN to hold arbitrary non-hierarchical properties is not at all obvious. For example, EV certificates contain two properties containing country code and other certificates might not contain any country code. >> Definitions: > > Is this also your take on how best to resolve the issue currently before > the CAB Forum about how to use consistent definitions of things like > "CA" in the BRs? > >> Certification Authority (CA) - a logical entity which uses its private >> key to sign certificates. > > Is this too broad? An intermediate certificate might meet this > definition. Why do we need this definition if we have CAO and CAKP? A CA is not a certificate. It is the tuple (CAKP, CADN). The requirements are not intended to only apply to Root CAs, so it would be accurate that a CA that is cross-signed/subordinated to a Root CA would meet the definition. The scope is designed to be explicitly applied to a CA then cascade down according to the rules. >> Cross-Certificate - a CA Certificate where the Issuer and Subject >> Distinguished Names are not the same > > I would call this an Intermediate Certificate. A cross certificate is an > informal term for a certificate which ties two previously-separated > trees of certificates together. This comes directly from RFC 5280, section 3.2: "This specification covers two classes of certificates: CA certificates and end entity certificates. CA certificates may be further divided into three classes: cross-certificates, self-issued certificates, and self-signed certificates. Cross-certificates are CA certificates in which the issuer and subject are different entities. Cross-certificates describe a trust relationship between the two CAs. [...] Self- signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths. End entity certificates are issued to subjects that are not authorized to issue certificates." >> End-entity Certificate - a Compliant Certificate either with no Basic >> Constraints extension or with a value of false in the CA component > > I thought you weren't supposed to do "CA: false" explicitly? The value is false but the Distinguished Encoding Rules (DER) that govern serialization into bytes say to leave out default values. >> Compliant Certificate - a Certificate as described in RFC 5280 as >> updated by RFC 6818 with the following exceptions: >> >> dNSName type GeneralNames included in a Subject Alternative Name >> extension may contain ‘*’ and ‘?’ > > Is "?" for CT? Yes. I was trying to ensure that these rules grandfather in things that are expected, which includes the draft Precerts at least one CA signs. >> Requirements: >> >> 1) The CA must have exactly one CA private key. > > One might add for clarity "A CAO operates one or more CAs." Yes, this is an important clarification. >> 7) End-entity Certificates must include an Extended Key Usage >> extension if one of the following is true: > > Why is this not required all the time? CAs issue lots of kinds of certificates. I wanted to avoid collisions with completely unrelated certificate types. >> 8) If the Extended Key Usage extension in an End-Entity certificate >> contains either the id-kp-serverAuth key purpose id or the special >> KeyPurposeId anyExtendedKeyUsage, or both, then the CA must follow the >> Baseline Requirements for publicly trusted certificates when issuing >> the certificate > > I would leave out anyExtendedKeyUsage - Firefox, at least, doesn't > recognise it. Agreed Firefox does not, but other browsers do. It ca be dropped if this is adopted as a Firefox-specific doc. >> 9) If the Extended Key Usage extension in an End-Entity certificate >> contains either the id-kp-codeSigning key purpose id or the special >> KeyPurposeId anyExtendedKeyUsage, or both, then the CA must follow the >> Minimum Requirements for the Issuance and Management of >> Publicly-Trusted Code Signing Certificates when issuing the >> certificate > > Again, if this were a Mozilla document, this would not be necessary. > >> 10) If the Extended Key Usage extension in an End-Entity certificate >> contains either the id-kp-emailProtection key purpose id or the >> special KeyPurposeId anyExtendedKeyUsage, or both, then the CA must: >> >> a) Ensure the End-Entity certificates follows the S/MIME Certificate >> Profile: Minimum > > What is that? The Google draft Andrew Whalley published. >> 11) If the Subject Distinguished Name of an End-Entity certificate >> contains any attributes of with the type jurisdictionCountryName (OID: >> 1.3.6.1.4.1.311.60.2.1.3), then the CAO must validate the details of >> the subject according to the Extended Validation Guidelines > > Why define EV this way, and not any other? EV is really hard to pin down. I purposefully avoided any discussion of Certificate Policy and Policy Mappings extensions, as there is little consistency in how they are handled in WebPKI. I could add a clause that inclusion of 2.23.140.1.1 in a Certificate Policy extension in an End-Entity certificate requires Extended Validation of the subject, but that alone would skip many EV certs that should be in scope. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
