Subject: [secdir] PKIX summary

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Mar 2011 06:40:05 -0400

About 47 individuals attended the PKIX meeting on Monday.

We reviewed document status (two in the RFC editors queue), and
5 in process in the WG.

Jim Schaad described his S/MIME capabilities doc, which is ready for WGLC.
He noted that the data structure defined therein might be a better choice
for the OCSP algorithm offering description. if we elect to adopt 
this would require that we revise the OCSP agility doc, which is 
already in the RFC Editor's queue. Tim Polk suggested that if the WG 
wants to make this change, he can probably persuade the IESG to allow 
this as an Auth_48 change.

Alexey Melinkov noted that the EAI WG is completing a revision RFC 
5335bis and RFC 5336bis. These changes will allow UTF-8 characters on 
both sides of the "@" in an e-mail address. RFC 5280 defines an 
RFC822 address as an SAN, but does not define addresses relative to 
UTF-8 encoding. Thus Alexey would like to see an update to 5280 that 
extends these two SANs to allow for UTF-8 encoding.  In the past we 
have seen a lack of widespread vendor support for UTF-8 in 
certificates (in DNs). Most recently it appeared that few RPs 
supported the matching rules that 5280 defines, in lieu of the 
simple, binary matching rules that were defined in 3280. This may 
argue for a return to the older, simple rules, if we want to support 
UTF-8 in these two SANs Paul argued that the alias issue is a red 
herring, since we may already have this problem, .e.g., foo.com and 
foo.net. So, we can bring to the list the topic of an update to 5280 
that makes UTF-8 support a SHOULD in DNS and e-mail address SANs, and 
to revert to the simpler matching rules.

The meeting ended with a presentation by Joe Salowey, discussing a 
proposal to pursue development of a lightweight cert management 
protocol, based on CMS. There was enthusiasm for this work, but also 
a lot of questions, e.g., what cert management functions will be 
supported and what are the primary use cases? Nonetheless, this is an 
interesting topic and it is likely that PKIX will pursue this effort.

Steve Kent
Stefan Santesson