Subject: [pkix] way forward for 5280

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2009 11:53:25 -0500

As noted in the meeting minutes, we need to make a minor revision to 
RFC 5280, so that it can progress, based on the implementation report 
generated by David Cooper.

David provided a thorough analysis of the options for string types 
for use with the user notice qualifier. Based on David's analysis, I 
suggest that we allow Visible String as a MAY, but keep use of UTF8 
as the SHOULD. I agree with David's suggestion that we consider 
dropping IA5. It doesn't appear to add any characters useful over 
Visible String, and it includes control characters, which might be 
used in malicious ways.

Does anyone object to this change, i.e., drop IA5, put VisibleString 
back as a MAY, and keep the SHOULD for UTF8.

If I hear no substantive arguments top the contrary by Friday, I will 
ask David to make this change and post the revised document. We will 
then begin a 2 week WGLC.

During this last call, ONLY comments on the revised text will be considered.

After WGLC, we will forward the document to Tim and the IESG.

Thanks,

Steve

---

From: Michael StJohns <[email-masked]>
Date: Mon, 16 Nov 2009 23:13:16 -0500

Steve - to clarify, IA5String moves to a SHOULD NOT or a MUST NOT?  

Or is it SHOULD NOT on create and MUST or SHOULD on the accept?

Thanks - Mike

At 11:53 AM 11/16/2009, Stephen Kent wrote:
>As noted in the meeting minutes, we need to make a minor revision to RFC 5280, so that it can progress, based on the implementation report generated by David Cooper.
>David provided a thorough analysis of the options for string types for use with the user notice qualifier. Based on David's analysis, I suggest that we allow Visible String as a MAY, but keep use of UTF8 as the SHOULD. I agree with David's suggestion that we consider dropping IA5. It doesn't appear to add any characters useful over Visible String, and it includes control characters, which might be used in malicious ways.
>
>Does anyone object to this change, i.e., drop IA5, put VisibleString back as a MAY, and keep the SHOULD for UTF8.
>
>If I hear no substantive arguments top the contrary by Friday, I will ask David to make this change and post the revised document. We will then begin a 2 week WGLC.
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Nov 2009 20:15:25 -0800

>During this last call, ONLY comments on the revised text will be considered.

Er, what happened to the problem with IDN processing?

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 17 Nov 2009 08:58:10 +0100

Hi, does this mean that Microsoft can now handle UTF-8 in user notices? 
It used to be that we had to violate rfc because MS requires BMPString.

Cheers,
Tomas

Stephen Kent wrote:
> As noted in the meeting minutes, we need to make a minor revision to RFC 
> 5280, so that it can progress, based on the implementation report 
> David provided a thorough analysis of the options for string types for 
> use with the user notice qualifier. Based on David's analysis, I suggest 
> that we allow Visible String as a MAY, but keep use of UTF8 as the 
> SHOULD. I agree with David's suggestion that we consider dropping IA5. 
> It doesn't appear to add any characters useful over Visible String, and 
> it includes control characters, which might be used in malicious ways.
> 
> *Does anyone object to this change, i.e., drop IA5, put VisibleString 
> back as a MAY, and keep the SHOULD for UTF8.*
> 
> ------------------------------------------------------------------------
>

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 17 Nov 2009 08:49:09 -0500

Michael StJohns wrote:

Steve - to clarify, IA5String moves to a SHOULD NOT or a
MUST NOT?

Here is the text that I have prepared for inclusion in the update RFC
based on Steve's proposal, which I interpreted as requesting that
VisibleString become a MAY and IA5String become a MUST NOT:

RFC 5280, Section 4.2.1.4, the tenth paragraph says:

|  An explicitText field includes the textual statement directly in

|  the certificate.  The explicitText field is a string with a

|  maximum size of 200 characters.  Conforming CAs SHOULD use the

|  UTF8String encoding for explicitText, but MAY use IA5String.

|  Conforming CAs MUST NOT encode explicitText as VisibleString or

|  BMPString.  The explicitText string SHOULD NOT include any control

|  characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When

|  the UTF8String encoding is used, all character sequences SHOULD be

|  normalized according to Unicode normalization form C (NFC) [NFC].

This paragraph is replaced with:

|  An explicitText field includes the textual statement directly in

|  the certificate.  The explicitText field is a string with a

|  maximum size of 200 characters.  Conforming CAs SHOULD use the

|  UTF8String encoding for explicitText, but MAY use VisibleString.

|  Conforming CAs MUST NOT encode explicitText as IA5String or

|  BMPString.  The explicitText string SHOULD NOT include any control

|  characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When

|  the UTF8String encoding is used, all character sequences SHOULD be

|  normalized according to Unicode normalization form C (NFC) [NFC].

As noted in the meeting
minutes,
we need to make a minor revision to RFC 5280, so that it can progress,
based on the implementation report generated by David Cooper.

David provided a thorough analysis of the options for string types for
use with the user notice qualifier. Based on David's analysis, I
suggest
that we allow Visible String as a MAY, but keep use of UTF8 as the
SHOULD. I agree with David's suggestion that we consider dropping IA5.
It
doesn't appear to add any characters useful over Visible String, and it
includes control characters, which might be used in malicious
ways.

Does anyone object to this change, i.e., drop IA5, put
VisibleString
back as a MAY, and keep the SHOULD for UTF8.

If I hear no substantive arguments top the contrary by Friday, I will
ask
David to make this change and post the revised document. We will then
begin a 2 week WGLC.

During this last call, ONLY comments on the revised text will be
considered.

Thanks,

Steve

pkix mailing list

[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Nov 2009 10:41:20 -0500

>Or is it SHOULD NOT on create and MUST or SHOULD on the accept?

Mike,

You are right that I was not precise enough in my characterization.

The current document says:

	SHOULD UTF8
	MAY IA5String
	MUST NOT VisibleString & BMPString

The proposal is:

	SHOULD UTF8
	MAY VisibleString
	MUST NOT IA5String or BMPString

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Nov 2009 10:44:59 -0500

At 8:58 AM +0100 11/17/09, Tomas Gustavsson wrote:
>Hi, does this mean that Microsoft can now handle UTF-8 in user 
>notices? It used to be that we had to violate rfc because MS 
>requires BMPString.
>
>Cheers,
>Tomas

I don't know what any specific MS PKI technology supports. But if it 
supports only BMPString, its compliance status is unchanged :-).

I don't recall David's report finding any certs that used BMPString. 
When you say "MS requires BMPString" do you mean the MS CA 
implementation, one or more MS applications, or what?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Nov 2009 10:55:07 -0500

>Er, what happened to the problem with IDN processing?

David said that he has not yet verified UTF8 support (by CAs) yet, 
but UTF8 isn't a MUST, only a SHOULD.

Does that address your question/comment?

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Nov 2009 08:10:30 -0800

At 10:55 AM -0500 11/17/09, Stephen Kent wrote:
>David said that he has not yet verified UTF8 support (by CAs) yet, but UTF8 isn't a MUST, only a SHOULD.
>

No, that is a different topic completely. The first major exception listed in draft-cooper-pkix-rfc5280-impl-report-00.txt covers processing rules for internationalized names. His report says that no implementations could be found.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Nov 2009 11:29:25 -0500

>...
>No, that is a different topic completely. The first major exception 
>listed in draft-cooper-pkix-rfc5280-impl-report-00.txt covers 
>processing rules for internationalized names. His report says that 
>no implementations could be found.

Whoops.

This is primarily a client issue, right? Section 7.1 established a 
MUST for comparison of IDNs, based on the LDAP StringPrep profile. 
Clients need to perform comparisons, e.g., a CA Subject name to CA 
name in a CRL, etc.  I reread David's comment as to why this would 
not be a problems client, due to CA adherence to uniform encoding of 
names, but you are right that we don't have an obvious way to address 
this apparent lack of conformance.

Russ & Tim, how would you like PKIX to proceed? We could wait for 
compliant implementations to appear (and we can try to encourage 
such), or we could downgrade the MUST to a SHOULD (but would the IESG 
be satisfied with this, given what I perceive as an overall desire to 
push for UTF8 support?).

Steve

---

From: Michael StJohns <[email-masked]>
Date: Tue, 17 Nov 2009 11:33:57 -0500

I'd suggest that since this is a deprecation that it be MUST NOT create and SHOULD accept to deal with interop with existing systems.  Just a thought.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Nov 2009 09:07:16 -0800

At 11:29 AM -0500 11/17/09, Stephen Kent wrote:
>This is primarily a client issue, right?

Probably not. The relying party (the "client") needs to match names with what the identity that the CA (the "server"?) intended. So, it's an issue for both. I see nothing in RFC 5280 section 7 that indicates that the material is only for relying parties: it says "conforming implementations" many places.

>Section 7.1 established a MUST for comparison of IDNs, based on the LDAP StringPrep profile. Clients need to perform comparisons, e.g., a CA Subject name to CA name in a CRL, etc.

This depends on your view of what the comparison is made to. I think it is made to the CA's naming rules.

>  I reread David's comment as to why this would not be a problems client, due to CA adherence to uniform encoding of names, but you are right that we don't have an obvious way to address this apparent lack of conformance.

We have no way of measuring "CA adherence to uniform encoding of names", do we?

>Russ & Tim, how would you like PKIX to proceed? We could wait for compliant implementations to appear (and we can try to encourage such), or we could downgrade the MUST to a SHOULD (but would the IESG be satisfied with this, given what I perceive as an overall desire to push for UTF8 support?).

Another alternative is to scrap the rules altogether and go back to exact match, with a note proposing how to achieve interop (CAs should normalize before issuing). I think this would achieve our goals of interoperability more than either of two given above.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 17 Nov 2009 18:05:38 +0000

> We have no way of measuring "CA adherence to uniform encoding of names", do we?

Do we need uniform encoding of names or just consistent encoding? For example if
a CA has decided to encode a name in a certain way it sticks to that encoding
afterwards and never uses a different one.

> Another alternative is to scrap the rules altogether and go back to exact match, with a note proposing how to achieve interop (CAs should normalize before issuing). I think this would achieve our g…

We already have this:

  CAs MUST encode the distinguished name in the subject field of a CA
   certificate identically to the distinguished name in the issuer field
   in certificates issued by that CA.  If CAs use different encodings,
   implementations might fail to recognize name chains for paths that
   include this certificate.  As a consequence, valid paths could be
   rejected.

but this only covers the special case of subject and issuer fields of CAs and
not CRLs, alternative names, name constraints etc.

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: Paul Hoffman <[email-masked]>
Date: Tue, 17 Nov 2009 10:34:06 -0800

>afterwards and never uses a different one.

We need uniform encoding because relying parties will have more than one trust anchor.

>   include this certificate.  As a consequence, valid paths could be

That only talks about encodings, not mappings. It is the mappings done through normalization that is the issue at hand.

>not CRLs, alternative names, name constraints etc.

Yes, there is that too. :-)

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 17 Nov 2009 18:58:23 +0000

> We need uniform encoding because relying parties will have more than one trust anchor.

Can you expand on why that needs uniform encoding?

Steve.

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 18 Nov 2009 09:21:19 +0100

I mean MS client software, when displaying certificates in Windows XP 
for example it will only display the user notice if it is a BMPString.
With this in mind I also assume that MS CA issues user notices with 
BMPString although I haven't verified.

Haven't tested on Vista or Win 7 though (I'm a linux fanboy :-)), wich 
was the reason for the question. I can make a test of this myself though.

Cheers,
Tomas

Stephen Kent wrote:
>> notices? It used to be that we had to violate rfc because MS requires 
>> BMPString.
>>
>> Cheers,
>> Tomas
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 18 Nov 2009 13:25:27 +0100

Hi,

I did some testing on windows 7 and unfortunately I can report that it
still does not show UTF-8 encoded user notice policy qualifiers.
BMP-string displays fine. Firefox handles UTF-8 just fine.

My guess it that many CAs create stuff that MS understands...and I'm not
saying that we should alter the RFC for MS, but that MS should fix their
implementation.

Cheers,
Tomas

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 18 Nov 2009 14:53:45 +0100

> generated by David Cooper.

If so, it would be a good time to include some other minor remarks.

First, the one I made in the following message 
http://www.imc.org/ietf-pkix/mail-archive/msg05602.htm about paragraph 
"7.3 Internationalized Domain Names in Distinguished Names".

The change I'm suggesting would make the standard more logical, as well 
as easier to both understand and implement. The current difference in 
IDN handling between 7.2 and 7.3 is just a quirk.
Also according to the implementation report, nobody implemented the IDN 
rules yet, so the change would have no consequences on implementations.

Second, there's a paragraph inside "8. Security Considerations" that is 
not a Security Consideration, it's a recommendation for the format of 
certificate. And as a consequence of being inside the wrong paragraph, 
it's easily missed by implementers (yes, implementers should read 
Security Considerations carefully. But the fact is they don't):
    CAs SHOULD NOT include URIs that specify https, ldaps, or similar
    schemes in extensions.  CAs that include an https URI in one of these
    extensions MUST ensure that the server's certificate can be validated
    without using the information that is pointed to by the URI.  Relying
    parties that choose to validate the server's certificate when
    obtaining information pointed to by an https URI in the
    cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess
    extensions MUST be prepared for the possibility that this will result
    in unbounded recursion.

I think some other placement should be found (4.2.3. Rules for URIS in 
extensions ?), *and* there should be a specific reference to it in the 
extensions that are most affected, that is cRLDistributionPoints, 
authorityInfoAccess, and subjectInfoAccesses.

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 18 Nov 2009 13:24:09 +0100

Hi,

Cheers,
Tomas

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Nov 2009 17:45:17 -0500

At 9:21 AM +0100 11/18/09, Tomas Gustavsson wrote:
>I mean MS client software, when displaying certificates in Windows 
>XP for example it will only display the user notice if it is a 
>BMPString.
>Haven't tested on Vista or Win 7 though (I'm a linux fanboy :-)), 
>wich was the reason for the question. I can make a test of this 
>myself though.
>
>Cheers,
>Tomas

Thanks for the clarification, and the offer to run tests on Vista and Win 7.
 From what you say, it appears that the MS client and CA software were 
not compliant with this aspect of 5280, and would not become so under 
the propose changes re user notice.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Nov 2009 14:49:34 -0500

At 11:33 AM -0500 11/17/09, Michael StJohns wrote:
>I'd suggest that since this is a deprecation that it be MUST NOT 
>create and SHOULD accept to deal with interop with existing systems. 
>Just a thought.
>

Mike,

That is an interesting suggestion, i.e., to separate the requirements 
for CAs vs. RPs.

The status for BMPString was the same in my before and after illustration.

So I assume that you would suggest that we label IA5String as MUST 
NOT create and SHOULD accept, right?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Nov 2009 14:55:37 -0500

At 9:07 AM -0800 11/17/09, Paul Hoffman wrote:
>Probably not. The relying party (the "client") needs to match names 
>with what the identity that the CA (the "server"?) intended. So, 
>it's an issue for both. I see nothing in RFC 5280 section 7 that 
>indicates that the material is only for relying parties: it says 
>"conforming implementations" many places.

I was thinking that an RP needs to match subject and issuer names in 
certs during path validation, and sometimes with names in CRLs. Also, 
an RP may have to perform a match with some local access control 
info, which might have come from an LDAP directory, hence the desire 
to use the LDAP string prep algorithm.

I think we agree that both CAs and RPs want to have names compared on 
a consistent basis, even though CAs are putting the names into 
structures and RPs are generally consuming the names and doing the 
comparisons.

>  >Section 7.1 established a MUST for comparison of IDNs, based on 
>the LDAP StringPrep profile. Clients need to perform comparisons, 
>e.g., a CA Subject name to CA name in a CRL, etc.
>

I'm not so clear on this point. Could you elaborate?

>  >  I reread David's comment as to why this would not be a problems 
>client, due to CA adherence to uniform encoding of names, but you 
>are right that we don't have an obvious way to address this apparent 
>lack of conformance.
>

Fair point.

>such), or we could downgrade the MUST to a SHOULD (but would the 
>IESG be satisfied with this, given what I perceive as an overall 
>desire to push for UTF8 support?).
>
>Another alternative is to scrap the rules altogether and go back to 
>exact match, with a note proposing how to achieve interop (CAs 
>should normalize before issuing). I think this would achieve our 
>goals of interoperability more than either of two given above.

True, but it also may not be seen to support the IETF (IESG/IAB) 
agenda of promoting use of UFT8 via our standards. That's why I asked 
Tim and Russ for their views on this issue.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Nov 2009 12:05:04 -0800

At 2:55 PM -0500 11/20/09, Stephen Kent wrote:
>I was thinking that an RP needs to match subject and issuer names in certs during path validation, and sometimes with names in CRLs. Also, an RP may have to perform a match with some local access control info, which might have come from an LDAP directory, hence the desire to use the LDAP string prep algorithm.
>
>I think we agree that both CAs and RPs want to have names compared on a consistent basis, even though CAs are putting the names into structures and RPs are generally consuming the names and doing the comparisons.

We are in agreement here.

>I'm not so clear on this point. Could you elaborate?

If the CA does not have the same normalization rules as the RP, the CA might create a name that the RP cannot match even though both are thinking the same thing. A simple example is "ÉxampleCo". If the CA encodes the first character as the two characters "capital E" and "combining accent", but the RP only can match it as the single character "capital E with accent", then there is no interoperability. Both forms are perfectly valid in Unicode.

>True, but it also may not be seen to support the IETF (IESG/IAB) agenda of promoting use of UFT8 via our standards. That's why I asked Tim and Russ for their views on this issue.

This has *nothing* to do with UTF8 encoding of characters. It is only about comparison and normalization.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 20 Nov 2009 15:28:40 -0500

Yup - comes down to the robustness principle.

I think "SHOULD accept" is probably appropriate for anything that previously was permitted to be created.  Going further, if all you're doing is comparing string stuff (- yes, related to the other part of this thread), there's no reason the RP has to actually interpret the blob or convert it to a native string type.  But that may be too wordy to be worth specifying.

Most of the implementations I've seen lump all the STRING types under a single implementation. They do a simple byte by byte compare to see if they match for comparison purposes so a "SHOULD accept" shouldn't be too onerous.  The hard part is generally figuring out how to select the ASN1 encoding  for any given input native string and that's what's getting deprecated.

All of this is a long winded way of saying yes to "MUST NOT create" and "SHOULD accept" for IA5String.

At 02:49 PM 11/20/2009, Stephen Kent wrote:
>That is an interesting suggestion, i.e., to separate the requirements for CAs vs. RPs.
>
>So I assume that you would suggest that we label IA5String as MUST NOT create and SHOULD accept, right?
>
>Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Nov 2009 15:33:58 -0500

A
>...
>
>>>  >Section 7.1 established a MUST for 
>>>comparison of IDNs, based on the LDAP 
>>>StringPrep profile. Clients need to perform 
>>>comparisons, e.g., a CA Subject name to CA 
>>>name in a CRL, etc.
>>>
>>>This depends on your view of what the 
>>>comparison is made to. I think it is made to 
>>>the CA's naming rules.
>>
>If the CA does not have the same normalization 
>rules as the RP, the CA might create a name that 
>the RP cannot match even though both are 
>thinking the same thing. A simple example is 
>"ÉxampleCo". If the CA encodes the first 
>character as the two characters "capital E" and 
>"combining accent", but the RP only can match it 
>as the single character "capital E with accent", 
>then there is no interoperability. Both forms 
>are perfectly valid in Unicode.

OK. How is an RP supposed to learn the 
normalization rules used by each CA? I had 
thought, apparently erroneously, that the string 
prep normalization step was designed to avoid 
this sort of problem, by establishing a uniform 
normalization alg.

>...
>  >True, but it also may not be seen to support 
>the IETF (IESG/IAB) agenda of promoting use of 
>UFT8 via our standards. That's why I asked Tim 
>and Russ for their views on this issue.
>
>This has *nothing* to do with UTF8 encoding of 
>characters. It is only about comparison and 
>normalization.

Sorry for the confusion. Yes, UTF8 support can be 
achieved without the normalization f(or 
comparison) provided by string prep, e.g., by 
mandating simple bit-by-bit comparison. But, as 
you noted, this does not ensure that an RP will 
see a match when a CA thought it would (due to a 
lack of normalization) and thus it may be seen as 
undermining use of UFT8, even when we allow UTF8 
syntaxt to be employed.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Nov 2009 12:48:46 -0800

At 3:33 PM -0500 11/20/09, Stephen Kent wrote:
>OK. How is an RP supposed to learn the normalization rules used by each CA? I had thought, apparently erroneously, that the string prep normalization step was designed to avoid this sort of problem, by establishing a uniform normalization alg.

It is, and that is what we have now. Another alternative is to say "the CA always normalizes, and the RP doesn't need to normalize if they are only comparing to normalized forms". That is, if the RP knows that the CA normalize, the RP can do exact matching on pre-normalized forms (that is, forms without combining characters or compatibility characters).

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 20 Nov 2009 15:55:54 -0500

Here is the text that is proposed for the explicitText field, which
simply takes the text in RFC 5280 and swaps IA5String and VisibleString:

Note that this text only imposes requirements on issuers, so
anything placing requirements on relying parties would be new.

However, if the intention is to add such a statement, here are two
statements from RFC 5280 that would be closely related:

1) Section 4.1.2.6 (Subject):

(c)  TeletexString, BMPString, and UniversalString are included

for backward compatibility, and SHOULD NOT be used for

certificates for new subjects.  However, these types MAY be

used in certificates where the name was previously

established, including cases in which a new certificate is

being issued to an existing subject or a certificate is being

issued to a new subject where the attributes being encoded

have been previously established in certificates issued to

other subjects.  Certificate users SHOULD
be prepared to

receive certificates with these types.

2) Section 7.1 (Internationalized Names in Distinguished Names):

Conforming implementations MUST

support UTF8String and PrintableString.  RFC 3280 required only

binary comparison of attribute values encoded in UTF8String, however,

this specification requires a more comprehensive handling of

comparison.  Implementations may encounter
certificates and CRLs with

names encoded using TeletexString, BMPString, or UniversalString, but

support for these is OPTIONAL.

If there is a desire to specify requirements for relying parties with
respect to explicitText, what is the proposed text?

Dave

Stephen Kent wrote:

Mike,

Steve

---

From: "Polk, William T." <[email-masked]>
Date: Fri, 20 Nov 2009 15:31:10 -0500

Jean-Marc,

I have asked David to include a fix for section 7.3 in his clarifications draft. We are limiting the document to
technical issues identified during the creation of the implementation report, but it makes sense to address
the ambiguity in 7.3 as well, since this is a feature where the implementation report could not demonstrate
interoperability.

I did not think it is appropriate to include your second change, since it is unrelated to the implementation
report.  I also see it as largely editorial, rather than technical - there is no debate about  the text, simply
where it would be best placed.  (As a side note, I think the text highlights a deployment issue rather than an
Implementation decision, so security considerations may be the right place after all.)

Thanks for keeping this one on our radar.

Tim

On 11/18/09 8:53 AM, "Jean-Marc Desperrier" <[email-masked]> wrote:

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 21 Nov 2009 00:01:57 +0100

I asked people at Microsoft to run a check on this and it appears after
quick code check that CAPI supports BMPString for encoding and VisibleString
and BMPString for decoding

This is somewhat contradictory to Tomas findings.

> MUST NOT IA5String or BMPString

If the purpose is to align with current deployment, then why not say:

SHOULD UTF8
MAY VisibleString or BMPString
MUST NOT IA5String

/Stefan

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 23 Nov 2009 09:37:21 +0100

Not contradicting, I would say confirming. I did not test VisibleString, 
only BMP vs UFT-8.
This is still good news, I can now try with VisibleString. If I can dump 
BMPString for VisibleString I would be slightly happier since we could 
make rfc compliant certificates by default.

I'll get around to testing VisibleString.

Cheers,
Tomas

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 24 Nov 2009 11:40:02 +0100

Hi,

Would you consider including some text that refers to this security 
consideration in the "CRL Distribution Points" paragraph (also 
"Authority Information Access" and "Subject Information Access"),
so that it gets less likely that implementers miss it ?

Polk, William T. wrote:
> [...]
> report.  I also see it as largely editorial, rather than technical -
> there is no debate about  the text, simply
> where it would be best placed.  (As a side note, I think the text
> highlights a deployment issue rather than an

---

From: Tom Gindin <[email-masked]>
Date: Wed, 25 Nov 2009 07:53:25 -0500

Actually, I don't see why that security consideration is 
appropriate for Subject Alternative Name.  It is obviously relevant to CRL 
Distribution Point (and thus Issuing Distribution Point as well), and it 
should emphasize LDAPS as much as HTTPS under distribution point.  It also 
matters for revocation-relevant access descriptors in AIA (mainly OCSP), 
but that leads to at least one other issue.
        I think there may be some inconsistency between our reaction to 
Max Pala's OCSP suggestions and this.  If no OCSP URI's should use HTTPS 
because of recursion, then such statements as Stefan's "running over https 
should be the appropriate solution rather than obfuscating serial numbers 
of the request" aren't appropriate.  HTTPS is a better way of avoiding 
leakage in the OCSP protocol than Max's suggestions, but not if it 
shouldn't be used because of recursion issues.
        Anyway, how would we prevent recursion for OCSP?  Tell OCSP server 
administrators to use only certificates with CRL's for their web sites? 
Tell OCSP clients not to check the OCSP server for revocation even when 
the URL says HTTPS (and hope they can stop the underlying SSL layer from 
doing so)?  Just tell SSL implementors to suppress checks if the transport 
address matches the AIA, and hope that no bimodal recursions occur? That's 
not very solid.

                Tom Gindin

From:
Jean-Marc Desperrier <[email-masked]>
To:
"Polk, William T." <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
11/24/2009 05:43 AM
Subject:
Re: [pkix] way forward for 5280
Sent by:
[email-masked]

Hi,

---

From: Patrick Patterson <[email-masked]>
Date: Wed, 25 Nov 2009 09:50:37 -0500

Hello Tom:

> but that leads to at least one other issue.
The current text for CRLDP has the sentence:

"When present,
   DistributionPointName SHOULD include at least one LDAP or HTTP URI."

And AIA has a similar sentence:

"When the id-ad-caIssuers
   accessMethod is used, at least one instance SHOULD specify an
   accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI."

If any security considerations take the position for using LDAPS and HTTPS, 
then I believe those sentences would have to be stricken, would they not?

What would this do to interoperable solutions?

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Nov 2009 11:31:45 -0500

Folks,

I don't mean to denigrate your suggested edits, bit recall that I 
said that we are making changes ONLY to address issues that arose in 
David's testing.  We can address other topics later.

Steve

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 25 Nov 2009 18:05:07 +0100

>     DistributionPointName SHOULD include at least one LDAP or HTTP URI."

But that's a SHOULD and not a MUST. ETSI TS 102 280 makes it a MUST and 
I honestly think it might be good if it were a MUST inside pkix also.

I have another absolutely nitpicky remark related to this.
The text also says :
    When a conforming
    CA includes a cRLDistributionPoints extension in a certificate, it
    MUST include at least one DistributionPoint that points to a CRL that
    covers the certificate for all reasons.

Which means that you can conform yourself to the letter to the 
specification by including a FTP cRLDistributionPoints for all reason 
together with a HTTP cRLDistributionPoints for only some reason.

So this text could be more precise as :
    MUST include at least one DistributionPoint that points to a CRL that
    covers the certificate for all reasons and which SHOULD use either a
    LDAP or HTTP URI.

---

From: Tom Gindin <[email-masked]>
Date: Fri, 27 Nov 2009 10:21:51 -0500

Patrick:

        I must not have been clear enough.  What I meant was that the 
security consideration in question implies that if DistributionPointName 
SHOULD include at least one HTTP or LDAP URI, that does NOT count any 
HTTPS or LDAPS URI.  Any similar change for caIssuers would encourage the 
use of HTTP or LDAP above HTTPS or LDAPS.  Remember, the lead sentence was 
"CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes 
in extensions."  I was attempting to restrict that to the revocation 
information extensions, rather than Subject Alternative Name and similar 
ones.

        Tom Gindin

From:
Patrick Patterson <[email-masked]>
To:
[email-masked]
Date:
11/25/2009 10:50 AM
Subject:
Re: [pkix] way forward for 5280
Sent by:
[email-masked]

Hello Tom:

"When present,

If any security considerations take the position for using LDAPS and 
HTTPS, 
then I believe those sentences would have to be stricken, would they not?