Subject: RE: draft minutes (using DNS for PKI support)

From: "David Cross" <[email-masked]>
Date: Thu, 23 Aug 2001 16:43:13 -0700

Sorry I missed the meeting.  Is this proposal based on RFC 2538?
 
Using DNS for PKI Support- Simon Josephson (RSA)
ID published as a personal draft. Focuses on using DNS to
hold certificates and CRLs. Works especially well for S/MINE, given
typical DNS lookup re MX records. Question is whether PKIX should
adopt this as a work item? Will discuss this on the list. (no slides)

http://www.ietf.org/rfc/rfc2538.txt?number=2538

David B. Cross

	-----Original Message-----
	From: Stephen Kent [mailto:[email-masked]] 
	Sent: Tuesday, August 21, 2001 7:32 AM
	To: [email-masked]
	Subject: draft minutes

	Folks,

	Please review the meeting minutes and get back to me with any
corrections by 8/28, so that I can submit them to the IETF secretariat
by the end of the month.

	Thanks,

	Steve
	--------

	PKIX WG Meeting 8/6/01
	Edited by Steve Kent (WG co-chairs)
	
	The PKIX WG met once during the 51st IETF. A total of
approximately 153
	individuals participated in the meeting.

	Tim quickly reviewed the agenda and document status, noting that
there are many
	I-Ds in progress. (see slides)
	
	Two new RFCs in the editor's queue:
	        RFC xxxx        Timestamp Protocol
	      RFC xxxx        Attribute Certificate Profile
	
	In the IESG Review Process:
	        PKIX Certificate and CRL Profile (a.k.a., son-of-2459)
	  Public Key Algorithms and Identifiers for the PKIX Certificate
profile
	
	Soon to be Submitted to IESG:
	     PKIX Roadmap
	    Repository Locator Service
	
	In WG Last Call:
	      none
	
	Close to WG last call:
	      Certificate Management Protocol (RFC 2510bis)
	   Certificate Request Message Framework (RFC 2511bis)
	     Transport Protocols for CMP
	     Online Certificate Status Protocol (OCSP v2)
	
	New Work:

	Logotype Certificates - Stefan Santesson (AddTrust)
	        Notion is to embed references to logos in certificates,
for
	CAs or for EEs,  to allow display of the logo as part of
certificate
	processing. Argument is that people relate to logos in the
physical
	world, and don't display certificate contents, so this is a way
to
	bring branding into PKIs. Major concern is that people could be
	mislead by certificates issued by a CA that binds inappropriate
logos
	to certificates it issues, e.g., there is no way to constrain
logo
	references the same way we can constrain names. Proposal is to
create
	a new extension for carrying a pointer (URL) to the logo image,
an
	indication of the image type, and a hash of the image. (see
slides)
	
	Supplemental Algorithms - Ari Singer (NTRU)
	New work item, to contain specs for a set of algorithms that
	COULD be used with PKIX data structures. Support for these
algorithms
	is not mandated, but this document will provide a reference for
these
	supplemental algorithms. Note need to include appropriate
	intellectual property warnings for proprietary algorithms, and
to
	distinguish between algorithms that are standards, vs,
proprietary.
	(see slides)
	
	PKI Disaster Recovery - Denis Pinkas (Integris)
	  The goal of this new work is to create an informational RFC
	which addresses how to deal with compromise or loss of use of a
CA,
	AA, or TSA key. Different requirements arise for EE signature
keys
	vs. EE encryption keys, and these are addressed separately. (see
	slides)
	
	Using DNS for PKI Support- Simon Josephson (RSA)
	ID published as a personal draft. Focuses on using DNS to
	hold certificates and CRLs. Works especially well for S/MINE,
given
	typical DNS lookup re MX records. Question is whether PKIX
should
	adopt this as a work item? Will discuss this on the list. (no
slides)

	Ongoing Work:
	
	LDAP V3 Profile and Certificate Matching Rules - David Chadwick
(Univ
	of Salford)
	Profile going well, looking for feedback before publishing as
	RFC. Matching rules work not as far along, but implementation
work
	now funded at Salford, which will help progress.
	
	CMC Update - Jim Schaad (Soaring Hawk Consulting)
	        Core functions largely unchanged, e.g., ASN syntax and
	processing rules wil be static. New set of CMC documents being
	issued, breaking into multiple pieces to allow easier
progression of
	pieces, e.g., transport, archive (also used by S/MIME),
compliance
	document. VeriSign hosted interoperability testing covering a
large
	number of protocol features. Several issues were uncovered
during
	testing. (see slides)
	
	CMP Update - Carlisle Adams (Entrust)
	        Interoperability testing yielded clarifications and the
	document is now ready to go to Draft Standard status.
	
	Proxy Certificates - Stephen Tuecke (Argonne Labs)
	  Revised ID has been published. Related draft in TLS WG. Not
	many attendees have read this draft, according to a show of
hands.
	Because it requires changes to certificate path validation,
there is
	a significant question about whether these changes should be
part of
	the base standards, or if this processing is a separate step to
be
	performed after standard path validation processing. (see
slides)
	
	OCSPv2 - Michael Myers (VeriSign)
	        Authors have decided to publish as experimental for now.
(no slides)
	
	SCVP - Ambarish Malpani (ValiCert)
	  No significant changes for now. (no slides)
	
	DPD/DPV - Denis Pinkas (Integris)
	    New ID posed to list. Incorporate new approach to DPV/DPD,
	using 3 protocols: DPV, DPD, and a separate protocol for
management
	of policy data used for validation or discovery. This allows the
DPD
	and DPV protocols to be smaller and simpler, because the
management
	of parameters used for DPD/DPV is part of a separate protocol.
The
	management protocol might not be implemented on many clients,
e.g.,
	thin clients. References to the parameters (policy) used for
	validation are OIDs, and there is a provision for a client to
NOT
	specify a policy, but have a server employ a default policy and
	return that to the user. Extensive use of hashes of ancillary
values
	to keep messages brief, but allow checking by client. DPV
proposal
	allows for validation re current time, or past time
(re-validation).
	DPV can return four answers, reflecting level of knowledge
available
	to the server, especially with regard to revocation data. DPD
and
	management protocol also presented in detail. (see slides)
	
	Policy Requirements for Timestamping  Authorities- Denis Pinkas
(Integris)
	        Discussion of this ETSI document and solicitation of
	comments. (see slides)

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 24 Aug 2001 10:54:02 +0200

David,

Yes it is.

However it updates the DNS domain owner name recommendations of RFC
2538, to be more "natural".  Basically this draft says that
certificates used for e.g. S/MIME should be stored under the simplest
translation of the email address of the user who owns the certificate.
RFC 2538 has more complex rules to derive a recommended owner name
which doesn't always make for a useful owner name.

I should point out that there are two problems with using the simplest
translation of the email address.  This is an open issue.  There are
two problems:

1) [email-masked] may have several certificates,
   e.g. S/MIME and PGP.  Storing them both under the same name wastes
   bandwidth and requires the client to intelligently select between
   them.

2) You cannot delegate management of the certificate hosting for the
   domain without also delegating management of the entire zone.
   E.g. say that example.com does not wish to host their certificates,
   but rather wishes that thirdparty.com hosts them.

Both problems may be solved by storing the certificates under a
subdomain, e.g. sjosefsson._smime.rsasecurity.com.  The owner name
will only be used by S/MIME certs, and it is possible to delegate
control of the entire subdomain to someone else.

Comments on this are most appreciated.

Regards Simon

"David Cross" <[email-masked]> writes:

>           -----Original Message----- From: Stephen Kent
>      [mailto:[email-masked]] Sent: Tuesday, August 21, 2001 7:32 AM To:
>      [email-masked] Subject: draft minutes     
>      
>
>           Folks,
>                
>
>      corrections by 8/28, so that I can submit them to the IETF
>      secretariat by the end of the month.
>                
>
>           Thanks,
>                
>
>           Steve
>           --------
>                
>
>           PKIX WG Meeting 8/6/01 Edited by Steve Kent (WG co-chairs)     
>      The PKIX WG met once during the 51st IETF. A total of approximately
>      153 individuals participated in the meeting.     
>      
>      there are many I-Ds in progress. (see slides)     
>      Two new RFCs in the editor's queue:         RFC xxxx       
>      Timestamp Protocol       RFC xxxx        Attribute Certificate
>      Profile     
>      In the IESG Review Process:         PKIX Certificate and CRL Profile
>      (a.k.a., son-of-2459)   Public Key Algorithms and Identifiers for
>      the PKIX Certificate profile     
>      Soon to be Submitted to IESG:      PKIX Roadmap     Repository
>      Locator Service     
>      In WG Last Call:       none     
>      Close to WG last call:       Certificate Management Protocol (RFC
>      2510bis)    Certificate Request Message Framework (RFC 2511bis)     
>      Transport Protocols for CMP      Online Certificate Status Protocol
>      (OCSP v2)     
>      New Work:     
>      
>      Logotype Certificates - Stefan Santesson (AddTrust)         Notion
>      is to embed references to logos in certificates, for CAs or for
>      EEs,  to allow display of the logo as part of certificate
>      processing. Argument is that people relate to logos in the physical
>      world, and don't display certificate contents, so this is a way to
>      logos to certificates it issues, e.g., there is no way to constrain
>      logo references the same way we can constrain names. Proposal is to
>      create a new extension for carrying a pointer (URL) to the logo
>      image, an indication of the image type, and a hash of the
>      image. (see slides)     
>      Supplemental Algorithms - Ari Singer (NTRU) New work item, to
>      contain specs for a set of algorithms that COULD be used with PKIX
>      data structures. Support for these algorithms is not mandated, but
>      this document will provide a reference for these supplemental
>      algorithms. Note need to include appropriate intellectual property
>      warnings for proprietary algorithms, and to distinguish between
>      algorithms that are standards, vs, proprietary.  (see slides)     
>      PKI Disaster Recovery - Denis Pinkas (Integris)   The goal of this
>      new work is to create an informational RFC which addresses how to
>      deal with compromise or loss of use of a CA, AA, or TSA
>      key. Different requirements arise for EE signature keys vs. EE
>      encryption keys, and these are addressed separately. (see slides)     
>      Using DNS for PKI Support- Simon Josephson (RSA) ID published as a
>      personal draft. Focuses on using DNS to hold certificates and
>      CRLs. Works especially well for S/MINE, given typical DNS lookup re
>      MX records. Question is whether PKIX should adopt this as a work
>      item? Will discuss this on the list. (no slides)     
>      
>      Ongoing Work:     
>      (Univ of Salford) Profile going well, looking for feedback before
>      publishing as RFC. Matching rules work not as far along, but
>      implementation work now funded at Salford, which will help progress.     
>      CMC Update - Jim Schaad (Soaring Hawk Consulting)         Core
>      functions largely unchanged, e.g., ASN syntax and processing rules
>      wil be static. New set of CMC documents being issued, breaking into
>      multiple pieces to allow easier progression of pieces, e.g.,
>      transport, archive (also used by S/MIME), compliance
>      document. VeriSign hosted interoperability testing covering a large
>      number of protocol features. Several issues were uncovered during
>      testing. (see slides)     
>      CMP Update - Carlisle Adams (Entrust)         Interoperability
>      testing yielded clarifications and the document is now ready to go
>      to Draft Standard status.     
>      Proxy Certificates - Stephen Tuecke (Argonne Labs)   Revised ID has
>      been published. Related draft in TLS WG. Not many attendees have
>      read this draft, according to a show of hands.  Because it requires
>      changes to certificate path validation, there is
>      part of the base standards, or if this processing is a separate step
>      to be performed after standard path validation processing. (see
>      slides)     
>      OCSPv2 - Michael Myers (VeriSign)         Authors have decided to
>      publish as experimental for now. (no slides)     
>      SCVP - Ambarish Malpani (ValiCert)   No significant changes for
>      now. (no slides)     
>      DPD/DPV - Denis Pinkas (Integris)     New ID posed to
>      list. Incorporate new approach to DPV/DPD, using 3 protocols: DPV,
>      DPD, and a separate protocol for management of policy data used for
>      validation or discovery. This allows the DPD and DPV protocols to be
>      smaller and simpler, because the management of parameters used for
>      DPD/DPV is part of a separate protocol. The management protocol
>      might not be implemented on many clients, e.g., thin
>      clients. References to the parameters (policy) used for validation
>      are OIDs, and there is a provision for a client to NOT specify a
>      policy, but have a server employ a default policy and return that to
>      the user. Extensive use of hashes of ancillary values to keep
>      messages brief, but allow checking by client. DPV proposal allows
>      for validation re current time, or past time (re-validation).  DPV
>      can return four answers, reflecting level of knowledge available to
>      the server, especially with regard to revocation data. DPD and
>      (Integris)         Discussion of this ETSI document and solicitation
>      of comments. (see slides)
>