Subject: RE: [ietf-dkim] RFC 4387 on Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP (fwd)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 7 Feb 2006 20:06:10 -0800

Might make sense in a policy record, but I don't think that either this
draft or the companion 4386 draft someone or other wrote that describes
an LDAP lookup scheme quite meshes with the DKIM approach where the data
flow of a signed message is driven first by the signature header and
then by the key record.

This is why I think that the correct placement for any cert linkage
would be from the key record to the cert. An alternative would be from
the key record to the cert store but that introduces an extra SRV lookup
and might be more complex to manage. The argument might be made that it
would be easier to manage for end user keys but we are not there yet.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> william(at)elan.net
> Sent: Tuesday, February 07, 2006 8:41 PM
> To: [email-masked]
> Subject: [ietf-dkim] RFC 4387 on Internet X.509 Public Key 
> Infrastructure Operational Protocols: Certificate Store 
> Access via HTTP (fwd)
> 
> 
> Obviously per your limited charter you'd consider this OT, 
> but still FYI.
> 
> ---------- Forwarded message ----------
> Date: Tue, 7 Feb 2006 17:25:38 -0800
> From: [email-masked]
> To: [email-masked], [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: RFC 4387 on Internet X.509 Public Key Infrastructure 
> Operational
>      Protocols: Certificate Store Access via HTTP
> 
> A new Request for Comments is now available in online RFC libraries.
> 
>          RFC 4387
> 
>          Title:      Internet X.509 Public Key Infrastructure
>                      Operational Protocols: Certificate Store 
> Access via
>                      HTTP
>          Author:     P. Gutmann,  Ed.
>          Status:     Standards Track
>          Date:       February 2006
>          Mailbox:    [email-masked]
>          Pages:      25
>          Characters: 63182
>          Updates/Obsoletes/SeeAlso:   None
> 
>          I-D Tag:    draft-ietf-pkix-certstore-http-09.txt
> 
>          URL:        http://www.rfc-editor.org/rfc/rfc4387.txt
> 
> The protocol conventions described in this document satisfy 
> some of the operational requirements of the Internet Public 
> Key Infrastructure (PKI).
> This document specifies the conventions for using the 
> Hypertext Transfer Protocol (HTTP/HTTPS) as an interface 
> mechanism to obtain certificates and certificate revocation 
> lists (CRLs) from PKI repositories.  Additional mechanisms 
> addressing PKIX operational requirements are specified in 
> separate documents.  [STANDARDS TRACK]
> 
> This document is a product of the Public-Key Infrastructure 
> (X.509) Working Group of the IETF.
> 
> This is now a Proposed Standard Protocol.
> 
> STANDARDS TRACK: This document specifies an Internet 
> standards track protocol for the Internet community,and 
> requests discussion and suggestions for improvements.Please 
> refer to the current edition of the Internet Official 
> Protocol Standards (STD 1) for the standardization state and 
> status of this protocol.  Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution 
> list should be sent to [email-masked].  Requests to be 
> added to or deleted from the RFC-DIST distribution list 
> should be sent to [email-masked].
> 
> Details on obtaining RFCs via FTP or EMAIL may be obtained by 
> sending an EMAIL message to [email-masked] with the 
> message body
> 
> help: ways_to_get_rfcs. For example:
> 
>          To: [email-masked]
>          Subject: getting rfcs
> 
>          help: ways_to_get_rfcs
> 
> Requests for special distribution should be addressed to 
> either the author of the RFC in question, or to 
> [email-masked].  Unless specifically noted 
> otherwise on the RFC itself, all RFCs are for unlimited distribution.
> 
> Submissions for Requests for Comments should be sent to 
> [email-masked].  Please consult RFC 2223, 
> Instructions to RFC Authors, for further information.
> 
> 
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
> 
> ...
> 
> 
> --22b50466d5aa20ab9f92be34617c09da
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>          RFC 4387
> 
>          Title:      Internet X.509 Public Key Infrastructure
>                      Operational Protocols: Certificate Store 
> Access via
>                      HTTP
>          Author:     P. Gutmann,  Ed.
>          Status:     Standards Track
>          Date:       February 2006
>          Mailbox:    [email-masked]
>          Pages:      25
>          Characters: 63182
>          Updates/Obsoletes/SeeAlso:   None
> 
>          I-D Tag:    draft-ietf-pkix-certstore-http-09.txt
> 
>          URL:        http://www.rfc-editor.org/rfc/rfc4387.txt
> 
> The protocol conventions described in this document satisfy 
> some of the operational requirements of the Internet Public 
> Key Infrastructure (PKI).
> This document specifies the conventions for using the 
> Hypertext Transfer Protocol (HTTP/HTTPS) as an interface 
> mechanism to obtain certificates and certificate revocation 
> lists (CRLs) from PKI repositories.  Additional mechanisms 
> addressing PKIX operational requirements are specified in 
> separate documents.  [STANDARDS TRACK]
> 
> This document is a product of the Public-Key Infrastructure 
> (X.509) Working Group of the IETF.
> 
> This is now a Proposed Standard Protocol.
> 
> STANDARDS TRACK: This document specifies an Internet 
> standards track protocol for the Internet community,and 
> requests discussion and suggestions for improvements.Please 
> refer to the current edition of the Internet Official 
> Protocol Standards (STD 1) for the standardization state and 
> status of this protocol.  Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution 
> list should be sent to [email-masked].  Requests to be 
> added to or deleted from the RFC-DIST distribution list 
> should be sent to [email-masked].
> 
> Details on obtaining RFCs via FTP or EMAIL may be obtained by 
> sending an EMAIL message to [email-masked] with the 
> message body
> 
> help: ways_to_get_rfcs. For example:
> 
>          To: [email-masked]
>          Subject: getting rfcs
> 
>          help: ways_to_get_rfcs
> 
> Requests for special distribution should be addressed to 
> either the author of the RFC in question, or to 
> [email-masked].  Unless specifically noted 
> otherwise on the RFC itself, all RFCs are for unlimited distribution.
> 
> Submissions for Requests for Comments should be sent to 
> [email-masked].  Please consult RFC 2223, 
> Instructions to RFC Authors, for further information.
> 
> 
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
> 
> ...
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> _______________________________________________
> NOTE WELL: This list operates according to 
> &lt;http://dkim.org/ietf-list-rules.html&gt;
> 
> 

_______________________________________________
NOTE WELL: This list operates according to &lt;http://dkim.org/ietf-list-rules.html&gt;

---

From: Mark Delany <[email-masked]>
Date: Wed, 8 Feb 2006 16:03:19 +0000

On Tue, Feb 07, 2006 at 08:06:10PM -0800, Hallam-Baker, Phillip allegedly wrote:
> Might make sense in a policy record,

You mean as a domain-level root for per-user keys? An interesting
thought.

The other issue with many of these "alternative" key storage specs is
that they just store keys. Adding all the Selector goop into these
would be a bit of a convolution and possibly an unwelcome one by the
original authors.

> would be easier to manage for end user keys

That would be my thinking. Assuming I was thinking at all...

> but we are not there yet.

Quite. The poor old chairs are having enough trouble getting focus on
the threats document. Yet alone to two or three other docs that need
to be complete before per-user can even sensibly discussed.

Mark.