Subject: RE: 3280bis: name constraints

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 16 Nov 2004 16:27:32 -0000

This is a truth with modification.

A relying party can always accept any certificates for any use for any
reason but that is not the point.

The point is to decide when path validation according to RFC 3280
rejects the certificate path as invalid. This is done within strict
rules.

Any constrained name form that is violated in the path renders the path
invalid. Critical or non-critical extensions does not make any
difference in this regard.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Terry Hayes
> Sent: den 16 november 2004 00:45
> To: David A. Cooper; Stephen Henson
> Cc: [email-masked]
> Subject: Re: 3280bis: name constraints
> 
> 
> In my opinion, a requirement such as this is too restrictive, and will
> prevent additional capabilities from being added to a PKI.
> 
> As long as an application never makes use of a particular name form,
it
> should be free to ignore constraints that apply to that name form.
Notice
> that to do this, it must recognize and process the name constraint
> extension as required by the extension processing rules.
> 
> If applications are required to reject certificates paths with
constraints
> for name forms that they do not recognize, they will be prevented from
> using certificates that have those name forms added to them for other
> applications.  This will impede the use of certificates for these new
> applications, since older clients will not be able to function.
> 
> Terry Hayes
> 
> 
> David A. Cooper wrote on 11/15/2004, 2:08 PM:
> >
> >
> > X.509 does have a rule that one must reject a critical extension
unless
> > you can process all of the fields in the extension. So, for name
> > constraints, if a critical nameConstraints extension includes a
> > constraint on a name form and that name form appears in the subject
> > field or subjectAltName extension of a subsequent certificate, then
path
> > must be rejected.

---

From: "piyush" <[email-masked]>
Date: Tue, 16 Nov 2004 09:59:04 -0800

The fact that the extension is a name constraint becomes immaterial if the 
path building software chooses to ignore it.
The software may ignore the extension if it is marked as non critical,  as 
per rfc 3280.

In practice, there may be some benefits to marking the name constraint 
extension non critical.
RP may configure the path building software to ignore/enforce the extension 
based on the importance of the transaction.
e.g. - for email validation, the RP may configure the path validation 
software to ignore name constraints.
      - for a million dollar internet transaction, the RP may configure the 
software to always enforce name constraints.

-Piyush

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: "Terry Hayes" <[email-masked]>; "David A. Cooper" 
<[email-masked]>; "Stephen Henson" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 16, 2004 8:27 AM
Subject: RE: 3280bis: name constraints

---

From: Stephen Henson <[email-masked]>
Date: Tue, 16 Nov 2004 18:15:39 +0000

piyush wrote:

> The fact that the extension is a name constraint becomes immaterial if 
> the path building software chooses to ignore it.
> The software may ignore the extension if it is marked as non critical,  
> as per rfc 3280.
> 

That's not my understanding. The relevant text in RFC3280 about 
criticality is:

> A certificate using system MUST reject the certificate if it encounters
> a critical extension it does not recognize; however, a non-critical
> extension MAY be ignored if it is not recognized.

I notice this doesn't explicitly say what an implementation should do if 
it encounters a non-critical extension that it does recognize.

I can recall threads where it was stated that recognized extensions MUST 
be processed irrespective of the their criticality. Should we clarify 
this in RFC3280bis?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 16 Nov 2004 13:48:26 -0500

Piyush,

This is not really how the criticality flag is supposed to be used.
According to the standard, an application may ignore a non-critical
extension if it can not process it.  Applications that can
process the extension are expected to do so, not to ask the user
whether to process or ignore the extension.

Setting a constraint extension like name constraints to non-critical
should be thought of as a path forward.  A CA that sets nameConstraints
to non-critical is indicating that it really wants relying parties to
reject certificates that do not satisfy the constraint, but the CA is
worried that many relying parties will be unable to process the
constraint.  Setting the extension to critical may cause such relying
parties to have to reject all certificates as a result of being unable
to process the constraint, even if certificates that violate the
constraint are unlikely to be encountered.  Setting the extension to
non-critical indicates that the CA wants the constraint to be imposed,
but is willing to take the risk that some relying parties will accept
certificates that violate the constraint rather than prevent such
relying parties from accepting any certificates at all.  As more and
more relying parties are upgraded to be able to fully process the
constraint, fewer and fewer relying parties will be at risk of
accepting certificates that violate the constraint.  If relying parties
interpret setting the criticality bit to FALSE to mean that the
extension can be processed or ignored at the relying parties whim, even
if the relying party is capable of processing the extension, then this
no longer works.

Dave

piyush wrote:

The fact
that the extension is a name constraint becomes immaterial if the path
building software chooses to ignore it.

RP may configure the path building software to ignore/enforce the
extension based on the importance of the transaction.

- for a million dollar internet transaction, the RP may configure
the software to always enforce name constraints.

-Piyush

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 16 Nov 2004 13:48:26 -0500

Piyush,

Dave

piyush wrote:

The fact

-Piyush

---

From: "piyush" <[email-masked]>
Date: Tue, 16 Nov 2004 09:59:04 -0800

-Piyush

---

From: Stephen Henson <[email-masked]>
Date: Tue, 16 Nov 2004 18:15:39 +0000

Steve.