Subject: last call for 3280bis

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Jun 2006 16:42:28 -0400

Folks,

Based on the latest message from David Cooper, I am initiating last 
call on "Internet X.509 Public Key Infrastructure, Certificate and 
Certificate Revocation List (CRL) Profile" 
(<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

The last call will last for two weeks. In deference to the U.S. 
Independence Dya holiday (which means July 3rd is a holiday for many 
folks), all comments must be received by July 5th.

Steve

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 21 Jun 2006 22:22:53 +0100

As a last call comment on RFC 3280bis I would like to raise the question
whether RFC 3280bis should include an escape clause clearly allowing
relying parties to select what validation logic they deploy on
certificate validation.

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies
and their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect
the list of EE certificate policies that are valid for a path. Yet many
deployments have included pure CA certificate policies in CA
certificates, policies that are not included in any EE certificates and
as such, policy processing is not possible in such PKIs.

Application wanting to use certificate policies in such PKI are simply
forced to either fail or selectively neglect certain path processing
rules. For a relying party such modification could be reasonable if the
security implications has been well though through.

However it is not clear if an implementation allowing such local
configuration could be regarded as standard compliant.

There are more examples where deploying applications in misconfigured
PKIs would need similar measures to work.

The pki4ipsec WG recently came to this conclusion in their PKI profile
and this lead to an intense debate which included core participants from
the PKIX WG.

The result was that the pki4ipsec profile included an escape clause as
follows:

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in order to permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

I'm basically asking if RFC 3280bis path validation needs a similar
escape clause or corresponding clarification that clearly allows local
configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of
standards compliant applications as long as this is not the default
functionality.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: [email-masked]
Subject: last call for 3280bis

Folks,

Based on the latest message from David Cooper, I am initiating last call
on "Internet X.509 Public Key Infrastructure, Certificate and
Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

Steve

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jun 2006 23:39:58 -0700

For various values, this I-D discusses how strings are to be
prepared using various profiles of the StringPrep algorithm.
However, the I-D fails to discuss whether the strings should
be prepared as "stored" or "query" strings (see Section 4
of RFC 3490).   The I-D should be revised so as to be clear
which strings are to be treated as "stored" strings and which
are to be treated as "query" strings.

Off the cuff, I suspect the right thing to do is:
  1) requiring each prepared string in a certificate/CRL be
    treated as "stored", and
  2) prepared strings to be compared against prepared strings
  in a certificate/CRL to be treated as either "query" or "stored".
This assures that each comparison between prepared strings
involves at least one "stored" string.

-- Kurt

At 01:42 PM 6/16/2006, Stephen Kent wrote:
>Folks,
>
>Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)
> 
>The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th.
>
>Steve

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 22 Jun 2006 13:52:22 +0100

In general we need a work through of the reference section to get the
references up to date.

Stefan Santesson

Senior Program Manager

Folks,

Steve

---

From: Tim Polk <[email-masked]>
Date: Thu, 22 Jun 2006 17:52:56 -0400

Kurt,

To be fair, the I-D does address stored strings in a couple of places, 
although we may have missed a reference.  Please review the quotes below, 
along with a couple of alternatives for one update, to see if we have it 
right...

Section 7.2 of this I-D includes the following text:

>To accommodate
>    internationalized domain names in the current structure, conforming
>    implementations MUST convert internationalized domain names to the
>    ASCII Compatible Encoding (ACE) format as specified in section 4 of
>    RFC 3490 before storage in the dNSName field.  Specifically,
>    conforming implementations MUST perform the conversion operation
>    specified in section 4 of RFC 3490 as follows:
>
>       * in step 1, the domain name SHALL be considered a "stored
>       string";
  (additional steps deleted)

Sections 7.5 includes a reference to the text in 7.2.  From 7.5:

>    Where the host-part (the domain of the addr-spec) contains an
>    internationalized name, the domain name MUST be converted from an IDN
>    to the ASCII Compatible Encoding (ACE) format as specified in section
>    7.2.
>
>    Two email addresses are considered to match if:
>
>       1) the local-part of each name is an exact match, AND
>       2) the host-part of each name matches using a case-insensitive
>       ASCII comparison.

I am probably missing some nuance, but this would seem to be sufficient for 
sections 7.2 and 7.5.

In section 7.3, we did not specify "stored" versus "query", because it does 
not seem to apply.  In this section 7.3, the domain component attribute 
contains only a single label, so we only perform the "ToASCII" operation.

>To represent a label from an IDN in the distinguished
>    name, the implementation MUST perform the "ToASCII" label conversion
>    specified in section 4.1 of RFC 3490.

As I said, the "ToASCII" operation doesn't seem to care about "stored" 
versus "query" so we didn't specify it.  However, the "ToASCII" operation 
does require specification of two additional inputs: the AllowUnassigned 
flag, and the UseSTD3ASCIIRules flag. We dropped the ball here.  We should 
have specified that the UseSTD3ASCIIRules flag should be set, and that 
AllowUassigned flag is *not* set.  (That works out to be the same as 
"stored" anyway, doesn't it?)

(1) How about the following revision to that sentence in 7.3:

To represent a label from an IDN in the distinguished name, the 
implementation MUST perform the "ToASCII" label conversion specified in 
section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but 
AllowUnassigned flag is not set.

(2) If I misinterpreted the specification of "ToASCII", and we do need to 
specify "stored" vs. "query", we could use this alternate text:

To represent a label from an IDN in the distinguished name, the 
implementation MUST perform the "ToASCII" label conversion specified in 
section 4.1 of RFC 3490, where the string preparation is performed as a 
"stored" string.

Am I correct that 7.2 and 7.5 are okay?  What do you think of the 
alternatives for 7.3?

Thanks,

Tim

At 11:39 PM 6/21/2006 -0700, Kurt D. Zeilenga wrote:

> on "Internet X.509 Public Key Infrastructure, Certificate and Certificate 
> Revocation List (CRL) Profile"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Jun 2006 16:43:12 -0700

Tim,
  
As far as nameprep goes, yes, AllowUnassigned is all about
"stored" v. "query" strings.  So, as you note, domain
label preparation is mostly okay.  (see below comments).

However, I do note that 7.1 says nothing about "stored"
v. "query" strings.  In this case, as one implementation
is preparing both strings in the comparison, treating
both as "stored" should be fine.

-- Kurt

> (additional steps deleted)

You might want to add:
        , hence the AllowUnassigned SHALL NOT be set.

since nameprep uses this flag to indicate the string has "stored"
handling.  Likewise in subsequent bullet set in this section.

>In section 7.3, we did not specify "stored" versus "query", because it does not seem to apply.  In this section 7.3, the domain component attribute contains only a single label, so we only perform the "ToASCII" operation.

It does (via AllowUnassigned).

>As I said, the "ToASCII" operation doesn't seem to care about "stored" versus "query" so we didn't specify it.  However, the "ToASCII" operation does require specification of two additional inputs: the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. We dropped the ball here.  We should have specified that the UseSTD3ASCIIRules flag should be set, and that AllowUassigned flag is *not* set.  (That works out to be the same as "stored" anyway, doesn't it?)

Yes.

>To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but AllowUnassigned flag is not set.
>(2) If I misinterpreted the specification of "ToASCII", and we do need to specify "stored" vs. "query", we could use this alternate text:
>
>To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the string preparation is performed as a "stored" string.

I prefer language that explicitly says that the string is to be
regarded as "stored" and (hence) the AllowUnassigned flag is
not set (see my comment regarding 7.2 text).

-- Kurt