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.

> and might be more complex to manage. The argument might be made that it
> 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.

> 
>  
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On Behalf Of 
> > william(at)elan.net
> > Sent: Tuesday, February 07, 2006 8:41 PM
> > To: [email protected]
> > 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 protected]
> > To: [email protected], [EMAIL PROTECTED]
> > Cc: [email protected], [email protected]
> > 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 PROTECTED]
> >          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 PROTECTED]  Requests to be 
> > added to or deleted from the RFC-DIST distribution list 
> > should be sent to [EMAIL PROTECTED]
> > 
> > Details on obtaining RFCs via FTP or EMAIL may be obtained by 
> > sending an EMAIL message to [EMAIL PROTECTED] with the 
> > message body
> > 
> > help: ways_to_get_rfcs. For example:
> > 
> >          To: [EMAIL PROTECTED]
> >          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 PROTECTED]  Unless specifically noted 
> > otherwise on the RFC itself, all RFCs are for unlimited distribution.
> > 
> > Submissions for Requests for Comments should be sent to 
> > [EMAIL PROTECTED]  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 PROTECTED]
> >          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 PROTECTED]  Requests to be 
> > added to or deleted from the RFC-DIST distribution list 
> > should be sent to [EMAIL PROTECTED]
> > 
> > Details on obtaining RFCs via FTP or EMAIL may be obtained by 
> > sending an EMAIL message to [EMAIL PROTECTED] with the 
> > message body
> > 
> > help: ways_to_get_rfcs. For example:
> > 
> >          To: [EMAIL PROTECTED]
> >          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 PROTECTED]  Unless specifically noted 
> > otherwise on the RFC itself, all RFCs are for unlimited distribution.
> > 
> > Submissions for Requests for Comments should be sent to 
> > [EMAIL PROTECTED]  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 protected]
> > https://www1.ietf.org/mailman/listinfo/ietf-announce
> > _______________________________________________
> > NOTE WELL: This list operates according to 
> > <http://dkim.org/ietf-list-rules.html>
> > 
> > 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> <http://dkim.org/ietf-list-rules.html>
> 
> 
_______________________________________________
NOTE WELL: This list operates according to 
<http://dkim.org/ietf-list-rules.html>

Reply via email to