[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft minutes (using DNS for PKI support)
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) sjosefsson@xxxxxxxxxxxxxxx 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" <dcross@xxxxxxxxxxxxx> writes:
> 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:kent@xxxxxxx] Sent: Tuesday, August 21, 2001 7:32 AM To:
> ietf-pkix@xxxxxxx 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)
>