Re: Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD
Kemp, David P. <DPKemp <at> missi.ncsc.mil>
2012-04-02 14:13:16 GMT
The first change would be from "maybe" petitioning Apple to "definitely"
calling their attention to the problem and requesting a fix.
DoD has encountered similar issues when deploying systems based on
commercial products. For example our policy is to use "Suite B"
cryptographic algorithms (ECC + AES) which are sometimes not supported
in the products we need to use. The acquisition process includes a
scheme for designating requirements as "Threshold" (required) and
"Objective (desired). CJCSM 3170.01
"Threshold values should be based on what is achievable through
the current state of technology as a minimum. The objective values
may be defined based on a goal for the end-state of the system."
If we were acquiring a system using Apple products, the objective would
be to comply with RFC 5280, and the threshold would be to comply with
RFC 5280 "except for requirements A, B, and C". Our solution would NOT
be to change technical standards such as 5280 to dilute requirements
based on the capabilities of current products.
As for what to do to get a system working using broken products, whether
you choose option b), c), or d) is not a matter for PKIX to decide. If
you think issuing non-standard certs is the most effective way to
transition from current to target systems, then by all means choose b).
From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of
Sent: Monday, April 02, 2012 9:25 AM
To: Erwann Abalea; Paul Hoffman
Cc: PKIX; Kathleen Wilson
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name
Constraints from MUST to SHOULD
Aside from maybe petitioning Apple to fix their code, what would you
advise Mozilla to do?
a) Require critical Name Constraints for "external" Sub-CAs ASAP,
thereby causing currently deployed Apple products to reject all certs
issued by these Sub-CAs.
b) Require Name Constraints, but specify that the critical flag need not
be set and mention that this requirement breaks RFC5280.
c) Not require Name Constraints. Instead, require all "external"
Sub-CAs to undergo a "full" audit.
On 02/04/12 14:06, Erwann Abalea wrote:
> I agree with Paul (and thus disagree with Rob).
> This is a constraint. If this constraint is set by the CA, the CA
> wants it to be enforced (else, why would it set this constraint?).
> Not so long ago, Apple had to correct a pretty bad behaviour with
> X.509 certificates, not enforcing basicConstraints:CA=False set to
> Nobody then thought of changing a MUST into a SHOULD to allow this
> behaviour. Apple choosed the only realistic solution, update its code.
> This is the same situation here. If Apple can't correctly handle a
> constraint imposed by the CA, or can't reject a certificate because of
> a critical-but-unknown extension, that's their problem, and they're
> putting their users at risk.
> That said, I'm an Apple user, and in the Mozilla context I'm
> following, Rob's proposition was not a bad one at first thought. Only
> 2012/4/2 Paul Hoffman <paul.hoffman <at> vpnc.org
> <mailto:paul.hoffman <at> vpnc.org>>
> On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote:
> > On 29/03/12 21:05, Rob Stradling wrote:
> > > RFC5280 says:
> > > "184.108.40.206. Name Constraints
> > > ...Conforming CAs MUST mark this extension as critical"
> > >
> > > Can anyone explain the reason for this requirement?
> > Everyone, thanks for your comments. There is certainly no
> consensus to change RFC5280 so that it doesn't advocate that Name
> Constraints be critical.
> > However, I wonder if we could arrive at a compromise...
> > PROPOSAL: Change the "MUST" to "SHOULD".
> > RFC2119 says:
> > '3. SHOULD This word, or the adjective "RECOMMENDED", mean
> > may exist valid reasons in particular circumstances to ignore
> > particular item, but the full implications must be understood
> > carefully weighed before choosing a different course.'
> > Now, I would say that the desire to avoid breaking all Apple
> devices is a "valid reason"! And I think "SHOULD" would still
> the appropriate message to implementers that they need to think
> carefully about these things.
> > Comments? Votes?
> Fully disagree. A number of people gave security reasons for the
> current wording. Watering down the security of the protocol
> a vendor made a bad decision and no one is doing conformance
> (which would have trivially picked this up) is not a good
> pkix mailing list
> pkix <at> ietf.org
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
COMODO CA Limited, Registered in England No. 04058690 Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
pkix mailing list
pkix <at> ietf.org
pkix mailing list
pkix <at> ietf.org