> > This is a great question! > > > > If the certificate is in scope of the BRs (i.e. the intermediate is either > > I or III), then we know Subscriber certificates MUST have a Key Usage > > (7.1.2.3(e) of the BRs). > > >From RFC 5280, Section 4.1.2.3, we know "When the keyUsage extension > > appears in a certificate, at least one of the bits MUST be set to 1." > > >From RFC 5280, Section 4.2.1.12, we know that if an EKU asserts > > id-kp-serverAuth (so (I, II, III)+C), then you're restricted to > > "digitalSignature, keyEncipherment, or keyAgreement" (those are the only > > consistent values enumerated) > > >From RFC 5246, 7.4.2 (and RFC 8446, Section 4.4.2.2), we can also see > > further restrictions on the allowed key usage bits of server certificates; > > this is not strictly an issuing prohibition, but worth considering. > > > > We can see through RFC 3279, 4055, 5756, 4491, 5480, and 5758 the relevant > > keyUsages for a variety of algorithms, such as RSA, DSA, and of course, EC. > > > > If I understand this question correctly, it's asking about whether the MAY > > of values (X, Y, Z) means SHALL NOT/MUST NOT for values (A, B, C). > > > > One interpretation says "You may set these values... or any other value". > > The MAY tells clients what they should be prepared for, potentially > > allowing them to reject any value outside of that if they're unprepared for > > it. > > Another interpretation says "These are the ONLY values that MAY be present. > > You MAY assert one or more of them, but you MUST NOT assert something else" > >
it seems we do have ambiguity. I talk with author, and I believe RFC will be fixed relatively soon. <https://mailarchive.ietf.org/arch/msg/spasm/32KJmCburr6tWciJHTjfv5piRxI> Tadahiko Ito _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
