archive-org.com » ORG » J » JOSEFSSON.ORG

Total: 236

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Kerberos V5 over TLS
    and 02 Diff between 00 and 01 Change History 2009 07 31 draft josefsson kerberos5 starttls 07 txt was published fixing nits 2009 03 09 draft josefsson kerberos5 starttls 06 txt was published adding a section on server certificate validation 2009 03 06 draft josefsson krb5starttls bootstrap 02 txt was published rewritten to use a new PA TLS type 2009 03 02 draft josefsson krb5starttls bootstrap 01 txt was published adds a PA ENC TIMESTAMP option 2009 03 02 draft josefsson krb5starttls bootstrap 00 txt was published addresses channel binding in krb5starttls 2009 03 02 draft josefsson kerberos5 starttls 05 txt was published removing the channel binding section 2008 12 05 draft josefsson kerberos5 starttls 04 txt was published fixing most PROTO writeup feedback 2007 12 03 draft josefsson kerberos5 starttls 03 txt was published with channel binding PA DATA 2007 08 17 The RFC editor announced RFC 5021 2007 05 14 The IESG approved draft ietf krb wg tcp expansion 01 2007 05 02 draft ietf krb wg tcp expansion 02 txt was announced attempts to resolve IETF LC issues 2007 04 02 IETF Last Call of draft ietf krb wg tcp expansion 01 ended 2007 03 14 IETF Last Call for draft ietf krb wg tcp expansion 01 issued 2006 10 23 draft josefsson kerberos5 starttls 02 txt was published 2006 10 03 draft josefsson kerberos5 starttls 01 txt was submitted This document now only describes the TLS part in the TCP expansion framework 2006 09 15 draft ietf krb wg tcp expansion 01 txt was announced attempts to resolve WGLC issues 2006 09 02 Some issues were brought up presumably a summary of the WGLC issues for draft ietf krb wg tcp expansion 00 2006 06 22 Working Group Last Call of 00 ended 2006 06 08

    Original URL path: http://www.josefsson.org/krb5starttls/ (2016-04-30)
    Open archived version from archive



  • name is derived from the content of the CERT RR data for example the Subject field in an X 509 certificate or the User ID field in OpenPGP keys A purpose based owner name is a name that a client retrieving CERT RRs ought to know already for example the host name of an X 509 protected service or the Key ID of an OpenPGP key The content based and purpose based owner name may be the same for example when a client looks up a key based on the From address of an incoming email Implementations SHOULD use the purpose based owner name guidelines described in this document and MAY use CNAME RRs at content based owner names or other names pointing to the purpose based owner name Josefsson Standards Track Page 7 RFC 4398 Storing Certificates in the DNS February 2006 Note that this section describes an application based mapping from the name space used in a certificate to the name space used by DNS The DNS does not infer any relationship amongst CERT resource records based on similarities or differences of the DNS owner name s of CERT resource records For example if multiple labels are used when mapping from a CERT identifier to a domain name then care must be taken in understanding wildcard record synthesis 3 1 Content Based X 509 CERT RR Names Some X 509 versions such as the PKIX profile of X 509 8 permit multiple names to be associated with subjects and issuers under Subject Alternative Name and Issuer Alternative Name For example the PKIX profile has such Alternate Names with an ASN 1 specification as follows GeneralName CHOICE otherName 0 OtherName rfc822Name 1 IA5String dNSName 2 IA5String x400Address 3 ORAddress directoryName 4 Name ediPartyName 5 EDIPartyName uniformResourceIdentifier 6 IA5String iPAddress 7 OCTET STRING registeredID 8 OBJECT IDENTIFIER The recommended locations of CERT storage are as follows in priority order 1 If a domain name is included in the identification in the certificate or CRL that ought to be used 2 If a domain name is not included but an IP address is included then the translation of that IP address into the appropriate inverse domain name ought to be used 3 If neither of the above is used but a URI containing a domain name is present that domain name ought to be used 4 If none of the above is included but a character string name is included then it ought to be treated as described below for OpenPGP names 5 If none of the above apply then the distinguished name DN ought to be mapped into a domain name as specified in 4 Example 1 An X 509v3 certificate is issued to CN John Doe DC Doe DC com DC xy O Doe Inc C XY with Subject Alternative Names of a string John the Man Doe b domain name john doe com and c URI The storage locations recommended in priority order would be Josefsson Standards Track Page 8 RFC 4398 Storing Certificates in the DNS February 2006 1 john doe com 2 www secure john doe com and 3 Doe com xy Example 2 An X 509v3 certificate is issued to CN James Hacker L Basingstoke O Widget Inc C GB with Subject Alternate names of a domain name widget foo example b IPv4 address 10 251 13 201 and c string James Hacker The storage locations recommended in priority order would be 1 widget foo example 2 201 13 251 10 in addr arpa and 3 hacker mail widget foo example 3 2 Purpose Based X 509 CERT RR Names Due to the difficulty for clients that do not already possess a certificate to reconstruct the content based owner name purpose based owner names are recommended in this section Recommendations for purpose based owner names vary per scenario The following table summarizes the purpose based X 509 CERT RR owner name guidelines for use with S MIME 17 SSL TLS 13 and IPsec 14 Scenario Owner name S MIME Certificate Standard translation of an RFC 2822 email address Example An S MIME certificate for postmaster example org will use a standard hostname translation of the owner name postmaster example org TLS Certificate Hostname of the TLS server IPsec Certificate Hostname of the IPsec machine and or for IPv4 or IPv6 addresses the fully qualified domain name in the appropriate reverse domain An alternate approach for IPsec is to store raw public keys 18 3 3 Content Based OpenPGP CERT RR Names OpenPGP signed keys certificates use a general character string User ID 5 However it is recommended by OpenPGP that such names include the RFC 2822 7 email address of the party as in Leslie Example If such a format is used the CERT ought to be under the standard translation of the email address into Josefsson Standards Track Page 9 RFC 4398 Storing Certificates in the DNS February 2006 a domain name which would be leslie host example in this case If no RFC 2822 name can be extracted from the string name no specific domain name is recommended If a user has more than one email address the CNAME type can be used to reduce the amount of data stored in the DNS For example ORIGIN example org smith IN CERT PGP 0 0 john smith IN CNAME smith js IN CNAME smith 3 4 Purpose Based OpenPGP CERT RR Names Applications that receive an OpenPGP packet containing encrypted or signed data but do not know the email address of the sender will have difficulties constructing the correct owner name and cannot use the content based owner name guidelines However these clients commonly know the key fingerprint or the Key ID The key ID is found in OpenPGP packets and the key fingerprint is commonly found in auxiliary data that may be available In this case use of an owner name identical to the key fingerprint and the key ID expressed in hexadecimal

    Original URL path: http://www.josefsson.org/rfc2538bis/rfc4398.txt (2016-04-30)
    Open archived version from archive

  • RFC 4398 (was: RFC 2538bis)
    The WG 06 draft Diff from 05 The WG 07 draft Diff from 06 The WG 08 draft Diff from 07 The WG 09 draft Diff from 08 See also the IETF I D tracker records Implementations Version 1 4 3 and later of GnuPG support CERT RRs Chronology 2006 03 31 RFC 4398 was announced 2006 03 14 Posted a proposal on how to solve David s problem 2006 01 28 David Shaw implemented CERT RRs for gpg and found a problem I asked the WG about what to do about indirect types 2006 01 12 The IANA found a problem in the document and I proposed a resolution of it 2005 10 10 2005 10 18 Addressed IESG review comments and answered questions about the document Submitted 09 2005 09 29 Submitted 08 2005 09 24 Pekka Savola suggested to add a reference column to the IANA table Incorporated the suggestion and prepared 08 2005 09 23 Received note about missing IANA considerations from Ólafur Guðmundsson so I added the reference column and submitted 07 2005 09 15 For the past days discussed and incorporated last call fixes for 06 The last call comments from Edward Lewis and Pekka Savola as well as the post last call comments from Peter Koch and Marcos Sanz has been resolved Handling the last call comment from Douglas Otis remains although some fixes to address it has been added 2005 09 08 Submitted 05 2005 09 06 Received two more comments prepared 05 2005 08 31 Received and acted on two anonymous review comments made to the IESG forwarded by Sam Hartman Started working on a WG 05 document 2005 08 30 Responded to the three last call comments and incorporated some changes Incorporated fixes for English mistakes received privately from Jason

    Original URL path: http://www.josefsson.org/rfc2538bis/ (2016-04-30)
    Open archived version from archive


  • host and port are discussed in 5 Josefsson Standards Track Page 4 RFC 4501 DNS URI May 2006 Because is used as the DNS label separator an escaping mechanism is required to encode a that is part of a DNS label The escaping mechanism is described in section 5 1 of RFC 1035 2 For example a DNS label of exa mple can be escaped as exa mple or exa 046mple However the URI specification disallows the character from occurring directly in URIs so it must be escaped as 5c The single DNS label exa mple is thus encoded as exa 5c mple The same mechanism can be used to encode other characters for example and Note that and 2e are equivalent within dnsname and are interchangeable This URI specification allows all possible domain names to be encoded provided the encoding rules are observed per 5 However certain applications may restrict the set of valid characters Care should be taken so that invalid characters in these contexts do not cause harm In particular host names in the DNS have certain restrictions It is up to these applications to limit this subset this URI scheme places no restrictions Intended usage Whenever it is useful for DNS resources to be referenced by protocol independent identifiers Often this occurs when the data is more important than the access method Since software in general has coped without this so far it is not anticipated to be implemented widely nor migrated to by existing systems but specific solutions especially security related may find this appropriate Applications and or protocols that use this scheme include Security related software DNS administration tools and network programming packages Interoperability considerations The data referenced by this URI scheme might be transferred by protocols that are not URI aware such as the DNS protocol This is not anticipated to have any serious interoperability impact Interoperability problems may occur if one entity understands a new DNS class type mnemonic that another entity does not This is an interoperability problem for DNS software in general although it is not a major practical problem for current DNS deployments as the DNS types and classes are fairly static To guarantee interoperability implementations can use integers for all mnemonics not defined in 2 Interaction with Binary Labels 10 or other extended label types has not been analyzed However binary labels appear to be infrequently used in practice Josefsson Standards Track Page 5 RFC 4501 DNS URI May 2006 Contact simon josefsson org Author Change Controller simon josefsson org 4 Examples A DNS URI is of the following general form This is intended to illustrate not define the scheme dns authority domain CLASS class TYPE type The following illustrates a URI for a resource with the absolute name www example org the Internet IN class and the Address A type dns www example org clAsS IN tYpE A Since the default class is IN and the default type is A the same resource can be identified by

    Original URL path: http://www.josefsson.org/dns-url/rfc4501.txt (2016-04-30)
    Open archived version from archive

  • Domain Name System Uniform Resource Identifiers
    for DNS data The Document rfc4501 txt draft josefsson dns url 13 txt latest published draft josefsson dns url txt fixes typos fixed during RFC AUTH48 draft josefsson dns url xml Differences compared to 13 Differences between live version and rfc4501 Open Issues There may be other issues as well but these are the things I m aware of The IETF I D tracker for this document IESG evaluation record Applications Java 1 3 JNDI Rebol URL support TCL dns package Timeline This timeline was re constructed in 2005 so major events may be lacking 2006 04 27 Fixed some AUTH48 complaints 2005 08 11 Prepared 14 to fix many typos 2005 08 08 Version 13 published Differences between 12 and 13 Mention the MIME types Removed illustrative examples of X 509 and OpenPGP usage in the introduction section as requested by Sam Hartman 2005 08 04 Went to Paris and resolved the remaining issue face to face Wrote and submitted 13 2005 07 14 Again asked for response to address the remaining IESG comment Question acknowledged but no response 2005 06 23 Asked for response to my reply on the remaining IESG comment No response 2005 05 31 All IESG objections except one cleared 2005 05 25 Version 12 published Differences between 11 and 12 To address IESG comments 2005 04 25 Discussed on IESG telechat 2005 02 10 Version 11 published Differences between 10 and 11 2005 02 Second IETF wide last call 2004 09 02 Version 10 published Differences between 09 and 10 2003 10 26 Version 9 published 2003 10 First IETF wide last call 2003 07 17 Discussed on W3C IETF teleconference 2003 07 08 Discussed on IAB teleconference I have not found any output or followup of the discussion 2001 08 13 Version 2

    Original URL path: http://www.josefsson.org/dns-url/ (2016-04-30)
    Open archived version from archive


  • CFWS CFWS preference preference CFWS CFWS parameter CFWS normally unused for extensions parameter is defined in RFC 2045 id 1 8HEXDIG HEXDIG is defined in RFC 5234 Matching of value is case insensitive url folded uri quoted url If the URL contains the character the quoted url form MUST be used quoted url DQUOTE folded uri DQUOTE DQUOTE is defined in RFC 5234 folded uri absoluteURI is defined in RFC 3986 FWS is defined in RFC 5234 preference sign encrypt signencrypt unprotected Matching of values is case insensitive The folded URI MAY contain folding whitespace FWS RFC5322 which is ignored To convert a folded URI to a absolute URI first apply standard RFC5322 unfolding rules replacing FWS with a single SP and then delete any remaining un encoded SP characters Folding may be used to shorten long lines 3 1 Primary Key ID field id The id parameter if present MUST hold the Key ID or key fingerprint for the primary key The value uses the hex RFC4648 notation The parameter value is case insensitive The length of the field determines whether it denotes a Key ID 8 hex symbols a long Key ID 16 hex symbols a v3 key fingerprint 32 hex symbols or a v4 key fingerprint 40 hex symbols Note that each of the following examples includes a comment which is optional Smasher Josefsson Expires November 2 2008 Page 5 Internet Draft The OpenPGP mail and news header field May 2008 id 12345678 short key ID id 1234567890ABCDEF long key ID id 1234567890abcdef0123456789ABCDEF01234567 v4 fingerprint id 1234567890ABCDEF0123456789ABCDEF v3 fingerprint deprecated 3 2 Key URL field url The url parameter if present MUST specify a URL where the public key can be found It is RECOMMENDED to use a common URL family such as HTTP RFC2616 or FTP RFC0959 The URL MUST be fully qualified MUST explicitly specify a protocol and SHOULD be accessible on the public Internet The content of where the URL points SHOULD be either an ASCII armored or binary OpenPGP packet containing the key A valid reason for storing something else may be if the key has been revoked For example url http example org pgp txt url http example org funny name txt If the URL contains the character the entire URL MUST be quoted as illustrated in the example 3 3 Protection Preference Field preference The preference parameter if present specify the quality of protection preferred by the sender The parameter value is case insensitive The available values are as follows A unprotected token means that the sender prefers not to receive OpenPGP protected e mails A sign token means that the sender prefers to receive digitally signed e mails A encrypt token means that the sender prefers to receive encrypted e mails A signencrypt token means that the sender prefers to receive encrypted and signed e mails Note that there is no normative requirement on the receiver to follow the stated preference For example preference sign preference unprotected preference ENCRYPT Smasher

    Original URL path: http://www.josefsson.org/openpgp-header/draft-josefsson-openpgp-mailnews-header.txt (2016-04-30)
    Open archived version from archive

  • The OpenPGP mail and news header
    to 05 The 05 document Diff compared to 04 The 04 document Diff compared to 03 The 03 document Diff compared to 02 The 02 document Diff compared to 01 The 01 document Diff compared to 00 The 00 document Updated pre draft specification Initial pre draft specification Resources IESG I D Status Tracker tools ietf org draft viewer Background and Related Work Discussion of this document happen in several places Initial discussion on gnupg devel Implementation aspects for the Gnus MUA Implementation aspects for the Mutt MUA Implementation aspects for the KMail MUA Standardization discussions in the OpenPGP WG Software with support of the header Gnus Enigmail see documentation related to the OpenPGP header SquirrelMail the PGP plugin If you know of more applications please let me know If you are curious what it means to implement this document here are some ideas Treat presence of the OpenPGP header as meaning that the sender support PGP MIME even if the message is not signed or encrypted Automatically adding the header if the user configured the MUA with her OpenPGP key ID Make the URLs within OpenPGP headers clickable to download the key from the URL and import it into the PGP implementation To add a Secure reply button that uses the Key ID information in the header to make a signed encrypted reply to a message If you have other ideas on how you can make use of the OpenPGP header let me know Timeline 2008 05 20 Submitted updated 06 version to address comments received from Alfred Hoenes 2008 04 15 Submitted updated 05 version 2008 04 08 Received AD review comments from Tim Polk that was quick 2008 04 07 Requested review from appsarea 2008 04 04 Tentative AD assigned 2008 04 03 Approached ADs to sponsor

    Original URL path: http://www.josefsson.org/openpgp-header/ (2016-04-30)
    Open archived version from archive


  • literals may contain CRLF within the text Binary transport is possible between systems that use the same end of line conventions Master files are in general ASCII but non ASCII octet values may occur and are treated as opaque values by DNS software compare RFC 1035 section 5 The master file format permits encoding arbitrary octet values by using the DDD encoding The use of DDD encoding can be more reliable than transporting non ASCII through MIME transports if data passes through a gateway that re encodes the character data Security considerations This media type identifies content as being DNS information in master file format as documented in RFC 1035 2 The DNS data may be security relevant as per to RFC 2538 7 or may be secured information as per to RFC 2535 6 Securing the content further may be done with standard techniques such as OpenPGP 5 or CMS 9 but this is outside of the scope here Further security assessments are not available at this point Interoperability considerations There are interoperability concerns with master files due to the widespread use of vendor specific extensions Non ASCII comments within master files may have been encoded in locally chosen character sets which may be difficult to transport interoperably Non ASCII data in general can become corrupted by re encoding gateways To achieve interoperability one can use the master file format described in the specification and the DDD encoding for non ASCII octets Further interoperability issues with unrecognized RR types exist which may be handled as discussed in section 5 of RFC 3597 8 Published specification The format of data that could be tagged with this MIME type is documented in RFC 1035 2 Josefsson Informational Page 3 RFC 4027 Domain Name System Media Types April 2005 Applications that use this media type DNS related software including software storing and using certificates stored in DNS Additional information Magic number s None File extension s soa and zone are known to be used Macintosh file type code s Unknown Person email address to contact for further information Simon Josefsson simon josefsson org Intended usage LIMITED USE Author change controller simon josefsson org 4 Security Considerations Security considerations are discussed in the security considerations clauses of the MIME registrations in sections 2 and 3 5 IANA Considerations The IANA has registered the MIME media types application dns and text dns by using the registration templates in sections 2 and 3 as per the procedure described in RFC 2048 3 6 Acknowledgements Thanks to D Eastlake for suggesting text dns Thanks to Keith Moore and Alfred Hoenes for reviewing this document The author acknowledges the RSA Laboratories for supporting the work that led to this document Josefsson Informational Page 4 RFC 4027 Domain Name System Media Types April 2005 A Disclaimer and License Regarding this entire document or any portion of it the author makes no guarantees and is not responsible for any damage resulting from its use The author grants irrevocable permission

    Original URL path: http://www.josefsson.org/dns-mime/rfc4027.txt (2016-04-30)
    Open archived version from archive



  •