Subject: draft-ietf-pkix-rfc3280bis-08.txt

From: "David A. Cooper" <[email-masked]>
Date: Fri, 23 Feb 2007 12:14:33 -0500

All,

Draft -08 of 3280bis is available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-08.txt.

A diff file highlighting the changes between drafts -07 and -08 is 
available at 
http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-07todraft3280bis-08_diff.html.

Here is a summary of the changes between drafts -07 and -08:

1) The ASN.1 for the privateKeyUsagePeriod and holdInstructionCode 
extensions were added back into the ASN.1 modules in Appendix A.  I was 
informed that any changes to the ASN.1 modules from RFC 3280 would 
require a change in the module OIDs, so now the only differences between 
ASN.1 modules in RFC 3280 and 3280bis are in the comments, with one 
exception.  The ASN.1 module in RFC 3280 defines ub-emailaddress-length, 
the maximum of the emailAddress attribute, as 128 characters.  However, 
PKCS #9 (RFC 2985), which contains the definition for the emailAddress 
attribute, specifies that the maximum length of an emailAddress 
attribute is 255 characters.  So in 3280bis, ub-emailaddress-length has 
been changed to 255.

2) Section 1 (Introduction) now includes a notes about the relationship 
between the ASN.1 modules in RFC 3280 and 3280bis and about the 
relationship between 3280 and RFC 4630, which will be obsoleted by 3280bis.

3) Section 4.2.1.2 (Subject Key Identifier) describes two methods based 
on SHA-1 for generating key identifiers and sections 4.2.1.1 and 4.2.1.2 
each contain a sentence recommending use of one of these methods for 
generating key identifiers where a key identifier has not already been 
established (this is unchanged).  These sentences in 4.2.1.1 and 4.2.1.2 
now explicitly state that it is acceptable to use a hash algorithm other 
than SHA-1 when generating key identifiers.

4) In section 4.2.1.3 (Key Usage), the description of the 
digitalSignature bit was slightly modified to clarify that "an  entity 
authentication service, a data origin authentication service, and/or an 
integrity service" are only examples of the types of digital signatures 
that may be verified using the public key that is in a certificate with 
the digitalSignature bit set.

5)  In section 4.2.1.6 (Subject Alternative Name), RFC 1738 was replaced 
with RFC 3986 as the source for rules on the URL syntax.  (In the 
remainder of 3280bis, RFC 1738 is still the reference for the specific 
HTTP and FTP URL schemes).

6) In section 4.2.1.10 (Name Constraints), RFC 1519 was replaced with 
RFC 4632 as the reference for Classless Inter-domain Routing (CIDR) 
notation and the example address range for IP address name constraints 
was changed to align with RFC 3330.  Also, the reference to 
draft-ietf-pkix-srvsan-04.txt [SRVSAN] was removed to ensure that 
3280bis could advance independent of draft-ietf-pkix-srvsan-04.txt.

7) The descriptions of the use of LDAP URIs in the 
cRLDistributionPoints, authorityInfoAccess, and subjectInfoAccess 
extensions (sections 4.2.1.13, 4.2.2.1, 4.2.2.2, and 5.2.7) were 
reworded based on comments from Kurt Zeilenga 
(http://www.imc.org/ietf-pkix/mail-archive/msg04434.html).

8) The final paragraph of section 7.1, which describes matching rules 
for DNs and RDNs, was reworded in order to make the text more clear.

9) In the references section, RFC 2560 and RFC 4519 were moved from 
"Normative References" to "Informative References".  RFC 1519 was 
replaced with RFC 4632.  All unused references were removed and a few 
new Informative References were added.

10) A paragraph was added to the security considerations section noting 
that emailAddress attributes are not case-sensitive (as defined by PKCS 
#9) even though RFC 2821 specifies that the local-part of an addr-spec 
(i.e., RFC 822 name) is case-sensitive.  The paragraph notes that this 
may lead to problems if an email address is included in an emailAddress 
attribute and the mail server that hosts that email address exploits the 
case-sensitivity of the local-parts of email addresses.

Dave

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 26 Feb 2007 19:21:24 +0100

Hi,

**The ASN.1 modules in appendix A are unchanged from RFC 3280, except
   that ub-emailaddress-length was changed from 128 to 255 in order to
   align with PKCS #9 [RFC 2985].**

isn't this an incompatible change from 3280? At least one well deployed
implementation checks for 128, i.e. openssl.

If this is acceptable, can someone explain why we cannot remove the 
restrictions
in the URI choice in order to align with X.509?

Peter

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Feb 2007 16:21:30 -0500

Peter:

If you find this unacceptable, we can assign new module OIDs.

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 26 Feb 2007 18:16:43 -0500

Peter,

In the case of the URI restrictions, I do not believe that there is a 
contradiction with X.509 since I read the text in section 4.2.1.6 of 
3280/3280bis as imposing a restriction on conforming CAs, not on what 
relying parties may accept.

In the case of the emailAddress attribute, specifying in the ASN.1 that 
the emailAddress attribute is defined as IA5String (SIZE 
(1..ub-emailaddress-length)) and then specify a value for 
ub-emailaddress-length of 128, this would seem to impose this limitation 
on both conforming CAs and relying parties.  Since this attribute is 
merely being imported from PKCS #9, which specifies a maximum length of 
255, I do not think that 3280bis should require relying parties to 
reject certificates that contain emailAddress attributes with lengths 
between 129 and 255 characters.

If there is a concern about backwards compatibility with clients that 
use the ASN.1 from RFC 3280, I would suggest that the solution is to 
leave ub-emailaddress-length at 255, but include a statement in section 
4.1.2.6 that says that conforming CAs must not include an emailAddress 
attribute with a value that is longer than 128 characters.  [Note that 
according to RFC 2821, an email address may be up to 320 characters in 
length, so even with the PKCS #9 defined maximum length of 255, some 
valid email addresses cannot be placed in the emailAddress attribute.]  
Since RFC 3280 (and 3280bis) discourages use of the emailAddress 
attribute, I would have no problem including another "roadblock" to its use.

Dave

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Feb 2007 23:47:56 +0000

I'd ask whether or not this is a *real* problem. If it is,
then yes, let's fix it. However, if not, then let's just get
this out the door - 3280bis has been a long time in the
oven already.

IMO this isn't a real problem, unless someone says that it
affects their code. I also have confidence that most of the
important code bases for X.509 are represented here and are
well able to object to changes that impact on their code.

So - who says this is a real problem for their code?

S.

PS: I don't really have a problem with this change. I do
have a problem however with the seemingly endless series
of similar changes that appear to slightly "improve" the
document but mostly just add delay.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 27 Feb 2007 00:25:22 +0000

> implementation checks for 128, i.e. openssl.

Note that the OpenSSL will not reject a certificate with a longer
emailAddress but it will refuse to create a certificate with an
emailAddress larger than 128.

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: Peter Sylvester <[email-masked]>
Date: Wed, 28 Feb 2007 12:49:33 +0100

> relying parties may accept.

unless my English is completely broken, I don't see in what way your 
statement is non-trivial
on last half-sentence.
I would understand it if you replace 'accept' by 'reject',

IMO 3280 is pretty weak distinguishing whether a MUST is for CAs or for 
relying parties.
One indication is for example

Some communities will need to supplement, or possibly replace, this
   profile in order to meet the requirements of specialized application
   domains or environments with additional authorization, assurance, or
   operational requirements.  

What are the legacy implementations in the following? CAs or relying 
parties?

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name extension (section 4.2.1.6 <http://tools.ietf.org/html/draft-ietf-pkix-rfc3280bis-08#section-4.2.1.6>) to describe such
   identities.  Simultaneous inclusion of the emailAddress attribute in
   the subject distinguished name to support legacy implementations is
   deprecated but permitted.

>
> In the case of the emailAddress attribute, specifying in the ASN.1 
> that the emailAddress attribute is defined as IA5String (SIZE 
> ub-emailaddress-length of 128, this would seem to impose this 
> limitation on both conforming CAs and relying parties.  Since this 
> attribute is merely being imported from PKCS #9, which specifies a 
> maximum length of 255, I do not think that 3280bis should require 
> relying parties to reject certificates that contain emailAddress 
> attributes with lengths between 129 and 255 characters.
Did I ask that 3280bis should require relying parties to reject 
something because it imposes restrictions to  CAs?
I didn't. But that is not the problem. 

I used the same argument for allowing urn:  I don't think that is wide 
deployment of relying party
implementation that rejects a certificate that has a URI with 'urn:'. 
There may be
implementations of CAs taht do not allow to put arbitrary strings into 
that field.
Thus, instead of defining another oethername form for urn, the whole 
limitations
of the URI choice can simply be removed IMO.

if 3280 merely reuses the email attribute and "probably?" erroneously 
limited its size and corrects this,
where is the difference in argumentation concerning the URI, i.e. 
allowing more values?

> leave ub-emailaddress-length at 255, but include a statement in 
> section 4.1.2.6 that says that conforming CAs must not include an 
> emailAddress attribute with a value that is longer than 128 
> characters.  [Note that according to RFC 2821, an email address may be 
> up to 320 characters in length, so even with the PKCS #9 defined 
> maximum length of 255, some valid email addresses cannot be placed in 
> the emailAddress attribute.]  Since RFC 3280 (and 3280bis) discourages 
> use of the emailAddress attribute, I would have no problem including 
> another "roadblock" to its use.
Since 3280 has made an error, it must remain so forever? At best I'd 
say: Although 255 chars are allows CAs may experience
problems in relying parties when using more than 128.
Why do YOU want to block anything? Is there anything dangerous with the 
email attribute, anyway, that's another story.