在 2019年4月10日星期三 UTC+8下午2:55:50,Lijun Liao写道:
> Let us consider the case that the CA unsets the critical flag unintendedly,
> e.g. using the default configuration. Which means there are no explizit
> reasons. Is it required that the CA to create an incident report to mozilla?
> 
> On Tue, 9 Apr 2019, 19:14 Ryan Sleevi <[email protected]> wrote:
> 
> >
> >
> > On Tue, Apr 9, 2019 at 10:39 AM Lijun Liao <[email protected]> wrote:
> >
> >> Just makes it clear: The extension KeyUsage is optional in subscriber's
> >> certificate. But what happens if it is present and is NOT critical?
> >>
> >
> > RFC 5280 says SHOULD, not MUST. RFC 2119 defines SHOULD as:
> >
> > 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
> >    may exist valid reasons in particular circumstances to ignore a
> >    particular item, but the full implications must be understood and
> >    carefully weighed before choosing a different course
> >
> > I think, in such an event, a CA may be reasonably asked to provide details
> > about what the valid reasons of the particular circumstances were to
> > deviate from that SHOULD, and how the full implications were understood and
> > weighed.
> >

For the $4.2.1.3. Key Usage in RFC 5280 says:
Conforming CAs MUST include this extension in certificates that contain public 
keys that are used to validate digital signatures on other public key 
certificates or CRLs.  When present, conforming CAs SHOULD mark this extension 
as critical.

The certificates that contain public keys that are used to validate digital 
signatures on other public key certificates or CRLs are CA certificates, not 
subscriber certificates. So in my opinion the requirement in RFC 5280 is for 
the CA certificates. Since there are both not a RFC non-compliant and BR 
non-compliant when it is not marked as critical in subscriber certificates, an 
incident report is not required.


Mirro
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to