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".

  • found It is RECOMMENDED to use a common URL family such as HTTP 12 or FTP 9 The URL MUST be fully qualified MUST explicitly specify a protocol and SHOULD be accessible on the public Internet For example url http example org pgp txt Smasher Josefsson Expires March 27 2006 Page 5 Internet Draft The OpenPGP mail and news header September 2005 3 3 Protection Preference Field preference The preference attribute value pair if present specify the quality of protection preferred by the sender The available choices are unprotected which means that the sender prefer not to receive OpenPGP protected e mails A sign token means that the sender prefer to receive digitally signed e mails A encrypt token means that the sender prefer to receive digitally encrypted e mails A signencrypt token means that the sender prefer to receive digitally encrypted and signed e mails Note that there is no technical requirement on the receiver to follow the stated preference For example preference sign preference unprotected preference ENCRYPT 4 Comments As discussed in section 3 2 3 of RFC 2822 comments may appear in header field bodies Comments are not intended to be interpreted by any application but to provide additional information for humans The following are examples of header field bodies with comments id B565716F key stored on non networked laptop id 12345678 1024 bit RSA Key for Encrypt or Sign id ABCD0123 created Sun Jan 2 02 25 15 CET 2005 5 Examples These are valid examples of ways in which this header may be used This list is not meant to be exhaustive but do reflect expected typical usages OpenPGP id 12345678 OpenPGP url http example com key txt OpenPGP preference unprotected OpenPGP url http example com key txt id 12345678 OpenPGP id 12345678 url http example com key txt preference signencrypt OpenPGP url http example com key txt down 2 3pm UTC id 12345678 this key is only used at the office preference sign unsigned emails are filtered away Smasher Josefsson Expires March 27 2006 Page 6 Internet Draft The OpenPGP mail and news header September 2005 6 Open Issues Should there be a supports field that signal whether the sender support inline PGP or PGP MIME As in supports inline mime or similar Should it be in preferred priority order This draft tentatively closes this issue by ignoring the matter until someone proposes text The ABNF definition is known to be under specified 7 Acknowledgements The content of this document builds on discussions with in alphabetical order Christian Biere Patrick Brunschwig Jon Callas Peter J Holzer Ingo Klocker Werner Koch Jochen Kupper Charles Lindsey Aleksandar Milivojevic Xavier Maillard Greg Sabino Mullane Thomas Roessler Moritz Schulte Olav Seyfarth Thomas Sjogren Paul Walker and Steve Youngs No doubt the list is incomplete We apologize to anyone we left out 8 Security Considerations These headers are intended to be a convenience in locating public keys They are neither secure nor intended to be Since header information is

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


  • Diff: draft-josefsson-openpgp-mailnews-header-01.txt - draft-josefsson-openpgp-mailnews-header-02.txt
    notation form or the fingerprint all using the hexadecimal 14 notation The length of the field imply the kind of key id i e short or long The length of the field imply the kind of key id i e short or long form or a v3 or v4 key form or a v3 or v4 key Note that each of the following examples includes a comment which is Note that each of the following examples includes a comment which is optional optional id 12345678 short key ID id 12345678 short key ID id 1234567890ABCDEF long key ID id 1234567890ABCDEF long key ID id 1234567890 ABCDEF 01234567890ABCDEF0123456 v4 fingerprint id 1234567890 abcdef 01234567890ABCDEF0123456 v4 fingerprint id 1234567890ABCDEF01234567890ABCDE v3 fingerprint deprecated id 1234567890ABCDEF01234567890ABCDE v3 fingerprint deprecated 3 2 Key URL field url 3 2 Key URL field url The url attribute value pair if present MUST specify a URL where The url attribute value pair if present MUST specify a URL where the public key can be found It is RECOMMENDED to use a common URL the public key can be found It is RECOMMENDED to use a common URL family such as HTTP 12 or FTP 9 The URL MUST be fully family such as HTTP 12 or FTP 9 The URL MUST be fully qualified MUST explicitly specify a protocol and SHOULD be qualified MUST explicitly specify a protocol and SHOULD be accessible on the public Internet accessible on the public Internet For example For example url http example org pgp txt url http example org pgp txt 3 3 Protection Preference Field preference The preference attribute value pair if present specify the quality of protection preferred by the sender The available choices are unprotected which means that the sender prefer not to receive OpenPGP protected e mails A sign token means that the sender prefer to receive digitally signed e mails A encrypt token means that the sender prefer to receive digitally encrypted e mails A signencrypt token means that the sender prefer to receive digitally encrypted and signed e mails Note that there is no technical requirement on the receiver to follow the stated preference For example preference sign preference unprotected preference ENCRYPT 4 Comments 4 Comments As discussed in section 3 2 3 of RFC 2822 comments may appear in As discussed in section 3 2 3 of RFC 2822 comments may appear in header field bodies Comments are not intended to be interpreted by header field bodies Comments are not intended to be interpreted by any application but to provide additional information for humans any application but to provide additional information for humans The following are examples of header field bodies with comments The following are examples of header field bodies with comments id B565716F key stored on non networked laptop id B565716F key stored on non networked laptop id 12345678 1024 bit RSA Key for Encrypt or Sign id 12345678 1024 bit RSA Key for Encrypt or Sign id ABCD0123 created Sun Jan 2

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


  • length of the field imply the kind of key id i e short or long form or a v3 or v4 key Note that each of the following examples includes a comment which is optional id 12345678 short key ID id 1234567890ABCDEF long key ID id 1234567890ABCDEF01234567890ABCDEF0123456 v4 fingerprint id 1234567890ABCDEF01234567890ABCDE v3 fingerprint deprecated 3 2 Key URL field url The url attribute value pair 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 12 or FTP 9 The URL MUST be fully qualified MUST explicitly specify a protocol and SHOULD be accessible on the public Internet For example url http example org pgp txt 4 Comments As discussed in section 3 2 3 of RFC 2822 comments may appear in header field bodies Comments are not intended to be interpreted by any application but to provide additional information for humans The following are examples of header field bodies with comments id B565716F key stored on non networked laptop id 12345678 1024 bit RSA Key for Encrypt or Sign id ABCD0123 created Sun Jan 2 02 25 15 CET 2005 5 Examples These are valid examples of ways in which this header may be used This list is not meant to be exhaustive but do reflect expected Smasher Josefsson Expires November 26 2005 Page 5 Internet Draft The OpenPGP mail and news header May 2005 typical usages OpenPGP 12345678 OpenPGP id 12345678 OpenPGP http example com key txt OpenPGP url http example com key txt OpenPGP url http example com key txt id 12345678 OpenPGP id 12345678 url http example com key txt OpenPGP url http example com key txt down 2 3pm UTC id 12345678 this key is only used at the office 6 Open Issues Should there be a supports field that signal whether the sender support inline PGP or PGP MIME As in supports inline mime or similar Should it be in preferred priority order The ABNF definition is known to be under specified 7 Acknowledgements The content of this document builds on discussions with in alphabetical order Christian Biere Patrick Brunschwig Jon Callas Peter J Holzer Ingo Klocker Werner Koch Jochen Kupper Charles Lindsey Aleksandar Milivojevic Xavier Maillard Greg Sabino Mullane Thomas Roessler Moritz Schulte Olav Seyfarth Thomas Sjogren Paul Walker and Steve Youngs No doubt the list is incomplete We apologize to anyone we left out 8 Security Considerations These headers are intended to be a convenience in locating public keys They are neither secure nor intended to be Since header information is easy to spoof information contained in headers should not be trusted The information must be verified How the information is verified is left as an exercise for the reader Applications that interpret the data within this header MUST NOT assume that the data is correct and MUST NOT present the data to the user in any way that would cause the user to assume that it

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

  • Diff: draft-josefsson-openpgp-mailnews-header-00.txt - draft-josefsson-openpgp-mailnews-header-01.txt
    V4 key packet that indicate the time the key was created expressed as an unsigned decimal integer parameter id id url url url url algo algo parameter See RFC 2045 for definition of parameter size size created created 3 1 Primary Key ID field id 3 1 Primary Key ID field id The id attribute value pair if present MUST define the primary The id attribute value pair if present MUST define the primary key ID The value MAY be prefixed with 0x The value MUST key ID The value MUST identify the key ID in either short or long identify the key ID in either short or long form or the form or the fingerprint all using the hexadecimal 14 notation fingerprint all using the hexadecimal 13 notation A short key ID is a 32 bit key ID represented as 8 characters A long key ID is a 64 bit key ID represented as 16 characters A v4 fingerprint is a 160 bit key ID represented as 40 characters A v3 fingerprint is a 128 bit key ID represented as 32 characters Note that each of the following examples includes a comment which is optional id 12345678 short key ID no 0x prefix id 0x12345678 short key ID id 0x1234567890ABCDEF long key ID id 0x1234567890ABCDEF01234567890ABCDEF0123456 v4 fingerprint id 0x1234567890ABCDEF01234567890ABCDE v3 fingerprint 3 2 Primary Key Algorithm field algo The algo attribute value pair if present MUST specify the The length of the field imply the kind of key id i e short or long algorithm of the primary key The algorithm of the primary key MUST form or a v3 or v4 key be presented as the value defined in section 9 1 of RFC 2440 Public Key Algorithms The value MUST be presented as an integer in decimal notation Note that each of the following examples includes a comment which is Note that each of the following examples includes a comment which is optional optional algo 1 RSA id 12345678 short key ID algo 17 DSA id 1234567890ABCDEF long key ID id 1234567890ABCDEF01234567890ABCDEF0123456 v4 fingerprint 3 3 Primary Key Size field size id 1234567890ABCDEF01234567890ABCDE v3 fingerprint deprecated The size attribute value pair if present MUST specify the size of the primary key The size of the primary key MUST be presented as the number of bits in the key s modulus The value MUST be presented as an integer in decimal notation Note that one of the following examples includes a comment which is optional size 1024 size 2048 bits 3 4 Key URL field url 3 2 Key URL field url The url attribute value pair if present MUST specify a URL where The url attribute value pair if present MUST specify a URL where the public key can be found It is RECOMMENDED to use a common URL the public key can be found It is RECOMMENDED to use a common URL family such as HTTP 1 1 or FTP 7 The URL MUST be fully family such as HTTP 1 2 or FTP 9 The URL MUST be fully qualified MUST explicitly specify a protocol and SHOULD be qualified MUST explicitly specify a protocol and SHOULD be accessible on the public Internet accessible on the public Internet For example For example url http example org pgp txt url http example org pgp txt 3 5 Key Creation Date field created This created attribute value pair if present MUST define the creation date of the primary key The creation date of the primary key MUST be presented as specified in section 5 5 2 of RFC2440 Public Key Packet Formats The value MUST be presented as a integer in decimal notation Note that the following example includes a comment which is optional created 1104629466 Sun Jan 2 01 31 06 UTC 2005 4 Comments 4 Comments As discussed in section 3 2 3 of RFC 2822 comments may appear in As discussed in section 3 2 3 of RFC 2822 comments may appear in header field bodies Comments are not intended to be interpreted by header field bodies Comments are not intended to be interpreted by any application but to provide additional information for humans any application but to provide additional information for humans The following are examples of header field bodies with comments The following are examples of header field bodies with comments id 0xB565716F key stored on non networked laptop id B565716F key stored on non networked laptop id 0x12345678 algo 1 RSA Encrypt or Sign id 12345678 1024 bit RSA Key for Encrypt or Sign id 0xABCD0123 created 1104629115 Sun Jan 2 02 25 15 CET 2005 id ABCD0123 created Sun Jan 2 02 25 15 CET 2005 5 Examples 5 Examples These are valid examples of ways in which this header may be used These are valid examples of ways in which this header may be used This list of examples is not meant to be exhaustive This list is not meant to be exhaustive but do reflect expected typical usages OpenPGP id 0x12345678 OpenPGP 12345678 OpenPGP id 0x12345678 algo 1 RSA size 2048 OpenPGP id 12345678 OpenPGP http example com key txt OpenPGP url http example com key txt OpenPGP url http example com key txt OpenPGP url http example com key txt OpenPGP url http example com key txt id 12345678 id 0x12345678 this key is only used at the office OpenPGP id 12345678 url http example com key txt OpenPGP url http example com key txt down 2 3pm UTC id 12345678 this key is only used at the office 6 Open Issues 6 Open Issues Should the algo size created fields be included They are supposedly only there for v3 keys Should there be a supports field that signal whether the sender Should there be a supports field that signal whether the sender support inline PGP or PGP MIME As in supports inline mime or support inline PGP or PGP MIME As in supports inline mime or similar

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


  • MAY be prefixed with 0x The value MUST identify the key ID in either short or long form or the fingerprint all using the hexadecimal 13 notation A short key ID is a 32 bit key ID represented as 8 characters A long key ID is a 64 bit key ID represented as 16 characters A v4 fingerprint is a 160 bit key ID represented as 40 characters A v3 fingerprint is a 128 bit key ID represented as 32 characters Note that each of the following examples includes a comment which is optional id 12345678 short key ID no 0x prefix id 0x12345678 short key ID id 0x1234567890ABCDEF long key ID id 0x1234567890ABCDEF01234567890ABCDEF0123456 v4 fingerprint id 0x1234567890ABCDEF01234567890ABCDE v3 fingerprint 3 2 Primary Key Algorithm field algo The algo attribute value pair if present MUST specify the algorithm of the primary key The algorithm of the primary key MUST be presented as the value defined in section 9 1 of RFC 2440 Public Key Algorithms The value MUST be presented as an integer in decimal notation Note that each of the following examples includes a comment which is optional algo 1 RSA algo 17 DSA 3 3 Primary Key Size field size The size attribute value pair if present MUST specify the size of the primary key The size of the primary key MUST be presented as the number of bits in the key s modulus The value MUST be presented as an integer in decimal notation Note that one of the following examples includes a comment which is Smasher Josefsson Expires July 8 2005 Page 5 Internet Draft The OpenPGP mail and news header January 2005 optional size 1024 size 2048 bits 3 4 Key URL field url The url attribute value pair 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 11 or FTP 7 The URL MUST be fully qualified MUST explicitly specify a protocol and SHOULD be accessible on the public Internet For example url http example org pgp txt 3 5 Key Creation Date field created This created attribute value pair if present MUST define the creation date of the primary key The creation date of the primary key MUST be presented as specified in section 5 5 2 of RFC2440 Public Key Packet Formats The value MUST be presented as a integer in decimal notation Note that the following example includes a comment which is optional created 1104629466 Sun Jan 2 01 31 06 UTC 2005 4 Comments As discussed in section 3 2 3 of RFC 2822 comments may appear in header field bodies Comments are not intended to be interpreted by any application but to provide additional information for humans The following are examples of header field bodies with comments id 0xB565716F key stored on non networked laptop id 0x12345678 algo 1 RSA Encrypt or Sign id 0xABCD0123 created 1104629115 Sun Jan 2 02 25 15

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


  • RFC 2396 openpgp parameter id id url url parameter See RFC 2045 for definition of parameter Examples OpenPGP 12345678 OpenPGP id 12345678 OpenPGP http example com key txt OpenPGP url http example com key txt OpenPGP url http example com key txt id 12345678 OpenPGP id 12345678 url http example com key txt OpenPGP url http example com key txt down 2 3pm UTC id 12345678 this key is only used at the office Q What problem is solved here A side effect of this effort may be to establish and document exactly what applications and or people use these headers for If you know of other uses please share Manual lookup of user s key Advertise that the user use OpenPGP Make it easier to download and import PGP keys of users Gnus will automatically download and import the key if you click the URL obvious privacy issues with that Generally important to make sure header information does not affect trust logic or processing in any way The header is a hint and everything should work if the header is absent or incorrect Open Issues aka Why I am Here Supports token Add a supports token that indicate sender

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


  • Josefsson Expires September 3 2004 Page 4 Internet Draft Domain Name System Media Types March 2004 3 MIME type registration of text dns To ietf types iana org Subject Registration of MIME media type text dns MIME media type name text MIME subtype name dns Required parameters None Optional parameters None Encoding considerations The data is textual and should be transfered in a line oriented mode Text literals may contain CRLF within the text Binary transports 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 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 encode the character data Security considerations This media type identify content as being DNS information in master file format as documented in RFC 1035 2 The DNS data may be security relevant according to RFC 2538 7 or secured information according to RFC 2535 6 Securing the content further may be done by standard techniques such as OpenPGP 5 or CMS 8 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 wide spread use of vendor specific extensions Non ASCII comments within master files may have been encoded in a 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 you can use the master file format described in the specification and the DDD encoding for non ASCII octets Published specification The format of data that could be tagged with this MIME type is documented in RFC 1035 2 Applications which use this media type DNS related software including software storing and using certificates stored in DNS Josefsson Expires September 3 2004 Page 5 Internet Draft Domain Name System Media Types March 2004 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 Josefsson Expires September 3 2004 Page 6 Internet Draft Domain Name System Media Types March 2004 4 Security Considerations Security considerations are discussed in the security considerations clause of the MIME registrations in section 2 and 3 5 IANA Considerations The IANA is asked to register the MIME media types application dns and text dns using the registration templates in section 2 and 3 according to the procedure described in RFC 2048 3 6 Acknowledgments Thanks to D Eastlake for suggesting text dns Thanks to Keith Moore for reviewing earlier versions of this

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


  • addresses DNS information are usually stored in text files so called zone files The format is described in RFC 1035 2 DNS data can also be stored in a format described in RFC 2540 5 It s intended to be used when archiving DNS data the format add timestamps to DNS data This document describe the registration of a MIME type for these two formats 2 Open Issues The issues discussed in this section should be resolved as this document matures Remove the section when no further issues exist Issues with the text dns format need to forbid INCLUDE does it have to be complete zone files need to do anything if no TTL and no SOA zone transfer format MIME parameter to replace ORIGIN Josefsson Expires July 24 2001 Page 3 Internet Draft MIME Registration of DNS data January 2001 3 MIME type registration of application dns To ietf types iana org Subject Registration of MIME media type application dns MIME media type name application MIME subtype name dns Required parameters none Optional parameters none Encoding considerations 7bit 8bit or binary Security considerations This definition only identifies the content as being detached DNS information as documented in RFC 2540 5 This data may be security relevant according to RFC 2538 4 or secured information according to RFC 2535 3 Interoperability considerations none Published specification the format of data that could be tagged with this MIME type is documented in RFC 2540 5 Applications which 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 none Macintosh File Type Code s unknown Person email address to contact for further information Simon Josefsson sjosefsson rsasecurity com Intended usage COMMON Author Change controller unknown Josefsson Expires July 24 2001 Page 4 Internet Draft MIME Registration of DNS data January 2001 4 MIME type registration of text dns To ietf types iana org Subject Registration of MIME media type text dns MIME media type name text MIME subtype name dns Required parameters none Optional parameters none Encoding considerations 7bit 8bit or binary Security considerations This definition only identifies the content as being DNS information in zone file format as documented in RFC 1035 2 The DNS data may be security relevant according to RFC 2538 4 or secured information according to RFC 2535 3 Interoperability considerations none Published specification the format of data that could be tagged with this MIME type is documented in RFC 1035 2 Applications which use this media type DNS related software Additional information Magic number s none File extension s none Macintosh File Type Code s unknown Person email address to contact for further information Simon Josefsson sjosefsson rsasecurity com Intended usage COMMON Author Change controller unknown Josefsson Expires July 24 2001 Page 5 Internet Draft MIME Registration of DNS data January 2001 Acknowledgement Thanks to D Eastlake for suggesting text dns References 1 Mockapetris P Domain Names Concepts and Facilities RFC 1034

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



  •