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".
  • Diff: draft-ietf-dnsext-rfc2538bis.txt - rfc4398.txt
    private certificate type not the OID private type Recognition of private certificate types need not be based on OID equality but can use various forms of types need not be based on OID equality but can use various forms of pattern matching such as OID prefix pattern matching such as OID prefix 2 2 Text Representation of CERT RRs 2 2 Text Representation of CERT RRs The RDATA portion of a CERT RR has the type field as an unsigned The RDATA portion of a CERT RR has the type field as an unsigned decimal integer or as a mnemonic symbol as listed in Section 2 1 decimal integer or as a mnemonic symbol as listed in Section 2 1 above above skipping to change at page 9 line 14 skipping to change at page 9 line 13 recommended in priority order would be recommended in priority order would be 1 john doe com 1 john doe com 2 www secure john doe com and 2 www secure john doe com and 3 Doe com xy 3 Doe com xy Example 2 An X 509v3 certificate is issued to CN James Hacker 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 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 domain name widget foo example b IPv4 address 10 251 13 201 and c string James Hacker hacker mail widget foo example The c string James Hacker hacker mail widget foo example The storage locations recommended in priority order would be storage locations recommended in priority order would be 1 widget foo example 1 widget foo example 2 201 13 251 10 in addr arpa and 2 201 13 251 10 in addr arpa and 3 hacker mail widget foo example 3 hacker mail widget foo example 3 2 Purpose Based X 509 CERT RR Names 3 2 Purpose Based X 509 CERT RR Names Due to the difficulty for clients that do not already possess a Due to the difficulty for clients that do not already possess a certificate to reconstruct the content based owner name purpose certificate to reconstruct the content based owner name based owner names are recommended in this section Recommendations purpose based owner names are recommended in this section for purpose based owner names vary per scenario The following table Recommendations for purpose based owner names vary per scenario The summarizes the purpose based X 509 CERT RR owner name guidelines for following table summarizes the purpose based X 509 CERT RR owner name use with S MIME 17 SSL TLS 13 and IPsec 14 guidelines for use with S MIME 17 SSL TLS 13 and IPsec 14 Scenario Owner name Scenario Owner name S MIME Certificate Standard translation of an RFC 2822 email S MIME Certificate Standard translation of an RFC 2822 email address Example An S MIME certificate for address Example An S MIME certificate for postmaster example org will use a standard postmaster example org will use a standard hostname translation of the owner name hostname translation of the owner name postmaster example org postmaster example org TLS Certificate Hostname of the TLS server TLS Certificate Hostname of the TLS server skipping to change at page 11 line 34 skipping to change at page 11 line 44 6 Acknowledgements 6 Acknowledgements Thanks to David Shaw and Michael Graff for their contributions to Thanks to David Shaw and Michael Graff for their contributions to earlier works that motivated and served as inspiration for this earlier works that motivated and served as inspiration for this document document This document was improved by suggestions and comments from Olivier This document was improved by suggestions and comments from Olivier Dubuisson Scott Hollenbeck Russ Housley Peter Koch Olaf M Dubuisson Scott Hollenbeck Russ Housley Peter Koch Olaf M Kolkman Ben Laurie Edward Lewis John Loughney Allison Mankin Kolkman Ben Laurie Edward Lewis John Loughney Allison Mankin Douglas Otis Marcos Sanz Pekka Savola Jason Sloderbeck Samuel Douglas Otis Marcos Sanz Pekka Savola Jason Sloderbeck Samuel Weiler Florian Weimer and the IANA No doubt the list is Weiler and Florian Weimer No doubt the list is incomplete We incomplete We apologize to anyone we left out apologize to anyone we left out 7 Security Considerations 7 Security Considerations By definition certificates contain their own authenticating By definition certificates contain their own authenticating signatures Thus it is reasonable to store certificates in non signatures Thus it is reasonable to store certificates in secure DNS zones or to retrieve certificates from DNS with DNS non secure DNS zones or to retrieve certificates from DNS with DNS security checking not implemented or deferred for efficiency The security checking not implemented or deferred for efficiency The results may be trusted if the certificate chain is verified back to a results may be trusted if the certificate chain is verified back to a known trusted key and this conforms with the user s security policy known trusted key and this conforms with the user s security policy Alternatively if certificates are retrieved from a secure DNS zone Alternatively if certificates are retrieved from a secure DNS zone with DNS security checking enabled and are verified by DNS security with DNS security checking enabled and are verified by DNS security the key within the retrieved certificate may be trusted without the key within the retrieved certificate may be trusted without verifying the certificate chain if this conforms with the user s verifying the certificate chain if this conforms with the user s security policy security policy If an organization chooses to issue certificates for its employees If an organization chooses to issue certificates for its employees placing CERT RR s in the DNS by owner name and if DNSSEC with NSEC placing CERT RRs in the DNS by owner name and if

    Original URL path: http://www.josefsson.org/rfc2538bis/rfc4398-from-draft-ietf-dnsext-rfc2538bis.diff.html (2016-04-30)
    Open archived version from archive

  • Diff: rfc2538.txt - rfc4398.txt
    but can use various forms of pattern matching so that for example subtype or version information can also be so that for example subtype or version information can also be encoded into the URI encoded into the URI The OID private type indicates a private format certificate specified The OID private type indicates a private format certificate specified by a an ISO OID prefix The certificate section will start with a by an ISO OID prefix The certificate section will start with a one byte unsigned OID length and then a BER encoded OID indicating one octet unsigned OID length and then a BER encoded OID indicating the nature of the remainder of the certificate section This can be the nature of the remainder of the certificate section This can be an X 509 certificate format or some other format X 509 certificates an X 509 certificate format or some other format X 509 certificates that conform to the IETF PKIX profile SHOULD be indicated by the PKIX that conform to the IETF PKIX profile SHOULD be indicated by the PKIX type not the OID private type Recognition of private certificate type not the OID private type Recognition of private certificate types need not be based on OID equality but can use various forms of types need not be based on OID equality but can use various forms of pattern matching such as OID prefix pattern matching such as OID prefix 2 2 Text Representation of CERT RRs 2 2 Text Representation of CERT RRs The RDATA portion of a CERT RR has the type field as an unsigned The RDATA portion of a CERT RR has the type field as an unsigned integer or as a mnemonic symbol as listed in section 2 1 above decimal integer or as a mnemonic symbol as listed in Section 2 1 above The key tag field is represented as an unsigned integer The key tag field is represented as an unsigned decimal integer The algorithm field is represented as an unsigned integer or a The algorithm field is represented as an unsigned decimal integer or mnemonic symbol as listed in RFC 2535 a mnemonic symbol as listed in 12 The certificate CRL portion is represented in base 64 and may be The certificate CRL portion is represented in base 64 16 and may be divided up into any number of white space separated substrings down divided into any number of white space separated substrings down to to single base 64 digits which are concatenated to obtain the full single base 64 digits which are concatenated to obtain the full signature These substrings can span lines using the standard signature These substrings can span lines using the standard parenthesis parenthesis Note that the certificate CRL portion may have internal sub fields Note that the certificate CRL portion may have internal sub fields but these do not appear in the master file representation For but these do not appear in the master file representation For example with type 254 there will be an OID size an OID and then example with type 254 there will be an OID size an OID and then the certificate CRL proper But only a single logical base 64 the certificate CRL proper However only a single logical base 64 string will appear in the text representation string will appear in the text representation 2 3 X 509 OIDs 2 3 X 509 OIDs OIDs have been defined in connection with the X 500 directory for OIDs have been defined in connection with the X 500 directory for user certificates certification authority certificates revocations user certificates certification authority certificates revocations of certification authority and revocations of user certificates of certification authority and revocations of user certificates The following table lists the OIDs their BER encoding and their The following table lists the OIDs their BER encoding and their length prefixed hex format for use in CERT RRs length prefixed hex format for use in CERT RRs id at userCertificate id at userCertificate joint iso ccitt 2 ds 5 at 4 36 joint iso ccitt 2 ds 5 at 4 36 0x 03 55 04 24 0x 03 55 04 24 id at cACertificate id at cACertificate joint iso ccitt 2 ds 5 at 4 37 joint iso ccitt 2 ds 5 at 4 37 0x 03 55 04 25 0x 03 55 04 25 id at authorityRevocationList id at authorityRevocationList joint iso ccitt 2 ds 5 at 4 38 joint iso ccitt 2 ds 5 at 4 38 0x 03 55 04 26 0x 03 55 04 26 skipping to change at page 5 line 26 skipping to change at page 7 line 26 0x 03 55 04 27 0x 03 55 04 27 3 Appropriate Owner Names for CERT RRs 3 Appropriate Owner Names for CERT RRs It is recommended that certificate CERT RRs be stored under a domain It is recommended that certificate CERT RRs be stored under a domain name related to their subject i e the name of the entity intended name related to their subject i e the name of the entity intended to control the private key corresponding to the public key being to control the private key corresponding to the public key being certified It is recommended that certificate revocation list CERT certified It is recommended that certificate revocation list CERT RRs be stored under a domain name related to their issuer RRs be stored under a domain name related to their issuer Following some of the guidelines below may result in the use in DNS Following some of the guidelines below may result in DNS names with names of characters that require DNS quoting which is to use a characters that require DNS quoting as per Section 5 1 of RFC 1035 backslash followed by the octal representation of the ASCII code for 2 the character such as 000 for NULL 3 1 X 509 CERT RR Names The choice of name under which CERT RRs are stored is important to clients that perform CERT queries In some situations the clients may not know all information about the CERT RR object it wishes to retrieve For example a client may not know the subject name of an X 509 certificate or the email address of the owner of an OpenPGP key Further the client might only know the hostname of a service that uses X 509 certificates or the Key ID of an OpenPGP key Some X 509 versions permit multiple names to be associated with Therefore two owner name guidelines are defined content based owner subjects and issuers under Subject Alternate Name and Issuer names and purpose based owner names A content based owner name is Alternate Name For example x 509v3 has such Alternate Names with derived from the content of the CERT RR data for example the an ASN 1 specification as follows 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 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 GeneralName CHOICE otherName 0 INSTANCE OF OTHER NAME otherName 0 OtherName rfc822Name 1 IA5String rfc822Name 1 IA5String dNSName 2 IA5String dNSName 2 IA5String x400Address 3 EXPLICIT OR ADDRESS Type x400Address 3 ORAddress directoryName 4 EXPLICIT Name directoryName 4 Name ediPartyName 5 EDIPartyName ediPartyName 5 EDIPartyName uniformResourceIdentifier 6 IA5String uniformResourceIdentifier 6 IA5String iPAddress 7 OCTET STRING iPAddress 7 OCTET STRING registeredID 8 OBJECT IDENTIFIER registeredID 8 OBJECT IDENTIFIER The recommended locations of CERT storage are as follows in priority The recommended locations of CERT storage are as follows in priority order order 1 If a domain name is included in the identification in the 1 If a domain name is included in the identification in the certificate or CRL that should be used certificate or CRL that ought to be used 2 If a domain name is not included but an IP address is included 2 If a domain name is not included but an IP address is included then the translation of that IP address into the appropriate then the translation of that IP address into the appropriate inverse domain name should be used inverse domain name ought to be used 3 If neither of the above it used but a URI containing a domain 3 If neither of the above is used but a URI containing a domain name is present that domain name should be used name is present that domain name ought to be used 4 If none of the above is included but a character string name is 4 If none of the above is included but a character string name is included then it should be treated as described for PGP names in included then it ought to be treated as described below for 3 2 below OpenPGP names 5 If none of the above apply then the distinguished name DN 5 If none of the above apply then the distinguished name DN should be mapped into a domain name as specified in RFC 2247 ought to be mapped into a domain name as specified in 4 Example 1 Assume that 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 https www secure john doe com 8080 Then the storage locations recommended in priority order would be 1 john doe com 2 www secure john doe com and 3 Doe com xy Example 2 Assume that an X 509v3 certificate is issued to CN James Example 1 An X 509v3 certificate is issued to CN John Doe DC Doe Hacker L Basingstoke O Widget Inc C GB with Subject Alternate names DC com DC xy O Doe Inc C XY with Subject Alternative Names of a of a domain name widget foo example b IPv4 address string John the Man Doe b domain name john doe com and c 10 251 13 201 and c string James Hacker URI https www secure john doe com 8080 The storage locations hacker mail widget foo example Then the storage locations recommended in priority order would be recommended in priority order would be 1 widget foo example 1 john doe com 2 201 13 251 10 in addr arpa and 2 www secure john doe com and 3 hacker mail widget foo example 3 Doe com xy 3 2 PGP CERT RR Names 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 hacker mail widget foo example The storage locations recommended in priority order would be PGP signed keys certificates use a general character string User ID 1 widget foo example RFC 2440 However it is recommended by PGP that such names include 2 201 13 251 10 in addr arpa and the RFC 822 email address of the party as in Leslie Example 3 hacker mail widget foo example Leslie host example If such a format is used the CERT should be under the standard translation of the email address into a domain 3 2 Purpose Based X 509 CERT RR Names name which would be leslie host example in this case If no RFC 822 name can be extracted from the string name no specific domain name is Due to the difficulty for clients that do not already possess a recommended 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 Leslie host example If such a format is used the CERT ought to be under the standard translation of the email address into 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 OpenPGP binary 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 16 is recommended For example ORIGIN example org 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP F835EDA21E94B565716F IN CERT PGP B565716F IN CERT PGP If the same key material is stored for several owner names the use of CNAME may help avoid data duplication Note that CNAME is not always applicable because it maps one owner name to the other for all purposes which may be sub optimal when two keys with the same Key ID are stored 3 5 Owner Names for IPKIX ISPKI IPGP and IACPKIX These types are stored under the same owner names both purpose and content based as the PKIX SPKI PGP and ACPKIX types 4 Performance Considerations 4 Performance Considerations Current Domain Name System DNS implementations are optimized for The Domain Name System DNS protocol was designed for small small transfers typically not more than 512 bytes including transfers typically below 512 octets While larger transfers will overhead While larger transfers will perform correctly and work is perform correctly and work is underway to make larger transfers more underway to make larger transfers more efficient it is still efficient it is still advisable at this time that every reasonable advisable at this time to make every reasonable effort to minimize effort be made to minimize the size of certificates stored within the the size of certificates stored within the DNS Steps that can be DNS Steps that can be taken may include using the fewest possible taken may include using the fewest possible optional or extensions optional or extension fields and using short field values for fields and using short field values for variable length fields that necessary variable length fields must be included 5 IANA Considerations The RDATA field in the DNS protocol may only hold data of size 65535 octets 64kb or less This means that each CERT RR MUST NOT contain more than 64kb of payload even if the corresponding certificate or certificate revocation list is larger This document addresses this by defining indirect data types for each normal type Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can Deploying CERT RRs to support digitally signed email changes the only be assigned by an IETF standards action RFC 2434 and this access patterns of DNS lookups from per domain to per user If document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE digitally signed email and a key certificate lookup based on CERT RRs Certificate types 0x0100 through 0xFEFF are assigned through IETF are deployed on a wide scale this may lead to an increased DNS load Consensus RFC 2434 based on RFC documentation of the certificate with potential performance and cache effectiveness consequences type The availability of private types under 0x00FD and 0x00FE Whether or not this load increase will be noticeable is not

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


  • a user It may also open up for a man in the middle attack where a certificate may be replaced in transit unless security measures are taken in the FTP or HTTP connection and in the domain name resolution While the LDAP protocol 5 technically is capable of searching for email addresses the question of how to locate the LDAP server has not been resolved Several attempts have been made to address this point though Some of these attempts are using DNS as well Josefsson Expires October 18 2001 Page 4 Internet Draft PKIX Operational Protocols DNS April 2001 1 3 2 Performance DNS queries are typically smaller and require less number of round trips to transfer a certificate compared to LDAP or FTP HTTP This is a concern in mobile and wireless applications 2 DNS Conventions PKIX Certificates and CRLs stored in DNS CERT records should use the PKIX certificate type as per RFC 2538 However the DNS owner name guidelines for PKIX certificates and CRLs described in RFC 2538 are for several applications not adequate Below we suggest a scheme that may be used in these applications It should be noted that the RFC 2538 guideliness MAY still be used and that one of these names MAY be CNAMEs to the other The RFC 2538 owner name guidelines is not adequate because they as well as other similar guidelines focus on the content of a certificate to determine how it should be stored This imposes a dilemma for a third party that wishes to locate a certificate for an remote entity e g identified with an mail address they need to know parts of or all of the DN of the certificate they want to retrieve In several PKIX application with the major example of S MIME communicating parties can in general only be assumed to know a limited set of information about the other entity Such as the mail address or hostname They do not know apriori the DN of the remote entity This discussion leads to a new DNS owner name guideline that focus on the entity that will perform lookups of the certificate rather than the publisher It is acknowledged that this limits the general usefulness of a certificate directory because a publisher will need to know how a certificate will be used in order to publish it However many PKIX applications are in environments when a publisher knows the intent of certificates e g S MIME SSL or IPSEC certificates and it will be possible to properly select a DNS owner name that matches what a remote entity would query for This document suggest that the following owner names should be used in the following situations Josefsson Expires October 18 2001 Page 5 Internet Draft PKIX Operational Protocols DNS April 2001 Scenario Owner name S MIME Certificate Standard translation of RFC 822 email address Example A S MIME certificate for postmaster example org will use a standard hostname translation of the owner name i

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


  • content of a certificate to determine how it should be stored This imposes a dilemma for a third party that wishes to locate a certificate for an remote entity e g identified with an mail address they need to know parts of the certificate they want to retrieve In email applications the parties can in general only be assumed to know a limited set of information about the other entity Such as the mail address They do not know apriori the X 509 DN of the remote entity When the RFC 2538 owner names for X 509 certificates are used clients that only knows e g the email address of a certificate owner cannot infer the DNS name where the certificate is used For example when the certificate for is stored in DNS the owner name depends on what the certificate Schlyter et al Expires May 11 2002 Page 3 Internet Draft Certificates in DNS for email November 2001 contains For instance if the users s URI is present in the certificate the owner name for the certificate should according to the RFC 2538 rules be the domain name in the URI A mail client that only knows the email address but not the URI cannot infer the domain name used 2 3 Administrative boundaries 3 Proposed representation As we have seen the DNS owner name guidelines described in RFC 2538 has several flaws They also do not make the owner name guidelines mandatory which would be a advantage for interoperable secure email Below we specify a scheme for applications that use RFC 2822 addresses to identify identities such as Internet Mail and the UseNet News N B the RFC 2538 guideliness MAY still be used in addition to the owner names specified here One of the owner names MAY be CNAMEs to the other 3 1 Algorithm to convert RFC 2822 address to domain name To encode a RFC 2822 addr spec into the string used to a DNS domain name as represented in zone files the local part is appended with mail and concatenated with the domain part INPUT from RFC 2882 EBNF addr spec local part domain OUTPUT domain name for DNS zone file local part mail domain 3 2 Case handling Even though the local part of a mail address may be case sensitive in theory the address SHOULD be converted to lower case before use 3 3 Examples A certificate for is stored at leslie mail example com A certificate for is stored at firstname lastname mail example com Schlyter et al Expires May 11 2002 Page 4 Internet Draft Certificates in DNS for email November 2001 4 Security Considerations Since certificates are digitally signed no additional integrity service is necessary Certificates do not need to be kept secret and anonymous access to certificates is generally acceptable thus no privacy service is necessary However clients that retrieve CRLs without some way of verifying the server run the risk of being sent a still current but

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


  • The certificate CRL portion is represented in base 64 and may be divided up into any number of white space separated substrings down to single base 64 digits which are concatenated to obtain the full signature These substrings can span lines using the standard parenthesis Note that the certificate CRL portion may have internal sub fields but these do not appear in the master file representation For example with type 254 there will be an OID size an OID and then the certificate CRL proper But only a single logical base 64 string will appear in the text representation 2 3 X 509 OIDs OIDs have been defined in connection with the X 500 directory for user certificates certification authority certificates revocations of certification authority and revocations of user certificates The following table lists the OIDs their BER encoding and their length prefixed hex format for use in CERT RRs Eastlake Gudmundsson Standards Track Page 4 RFC 2538 Storing Certificates in the DNS March 1999 id at userCertificate joint iso ccitt 2 ds 5 at 4 36 0x 03 55 04 24 id at cACertificate joint iso ccitt 2 ds 5 at 4 37 0x 03 55 04 25 id at authorityRevocationList joint iso ccitt 2 ds 5 at 4 38 0x 03 55 04 26 id at certificateRevocationList joint iso ccitt 2 ds 5 at 4 39 0x 03 55 04 27 3 Appropriate Owner Names for CERT RRs It is recommended that certificate CERT RRs be stored under a domain name related to their subject i e the name of the entity intended to control the private key corresponding to the public key being certified It is recommended that certificate revocation list CERT RRs be stored under a domain name related to their issuer Following some of the guidelines below may result in the use in DNS names of characters that require DNS quoting which is to use a backslash followed by the octal representation of the ASCII code for the character such as 000 for NULL 3 1 X 509 CERT RR Names Some X 509 versions permit multiple names to be associated with subjects and issuers under Subject Alternate Name and Issuer Alternate Name For example x 509v3 has such Alternate Names with an ASN 1 specification as follows GeneralName CHOICE otherName 0 INSTANCE OF OTHER NAME rfc822Name 1 IA5String dNSName 2 IA5String x400Address 3 EXPLICIT OR ADDRESS Type directoryName 4 EXPLICIT 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 Eastlake Gudmundsson Standards Track Page 5 RFC 2538 Storing Certificates in the DNS March 1999 1 If a domain name is included in the identification in the certificate or CRL that should 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 should be used 3 If neither

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


  • field as an unsigned integer or as a mnemonic symbol as listed in section 2 1 above The key tag field is represented as an unsigned integer The algorithm field is represented as an unsigned integer or a mnemonic symbol as listed in 8 The certificate CRL portion is represented in base 64 and may be divided up into any number of white space separated substrings down to single base 64 digits which are concatenated to obtain the full signature These substrings can span lines using the standard parenthesis Note that the certificate CRL portion may have internal sub fields but these do not appear in the master file representation For example with type 254 there will be an OID size an OID and then the certificate CRL proper But only a single logical base 64 string will appear in the text representation 2 3 X 509 OIDs OIDs have been defined in connection with the X 500 directory for user certificates certification authority certificates revocations of certification authority and revocations of user certificates The following table lists the OIDs their BER encoding and their length prefixed hex format for use in CERT RRs Josefsson Expires March 5 2005 Page 5 Internet Draft Storing Certificates in the DNS September 2004 id at userCertificate joint iso ccitt 2 ds 5 at 4 36 0x 03 55 04 24 id at cACertificate joint iso ccitt 2 ds 5 at 4 37 0x 03 55 04 25 id at authorityRevocationList joint iso ccitt 2 ds 5 at 4 38 0x 03 55 04 26 id at certificateRevocationList joint iso ccitt 2 ds 5 at 4 39 0x 03 55 04 27 3 Appropriate Owner Names for CERT RRs It is recommended that certificate CERT RRs be stored under a domain name related to their subject i e the name of the entity intended to control the private key corresponding to the public key being certified It is recommended that certificate revocation list CERT RRs be stored under a domain name related to their issuer Following some of the guidelines below may result in the use in DNS names of characters that require DNS quoting which is to use a backslash followed by the octal representation of the ASCII code for the character such as 000 for NULL 3 1 X 509 CERT RR Names Some X 509 versions permit multiple names to be associated with subjects and issuers under Subject Alternate Name and Issuer Alternate Name For example x 509v3 has such Alternate Names with an ASN 1 specification as follows GeneralName CHOICE otherName 0 INSTANCE OF OTHER NAME rfc822Name 1 IA5String dNSName 2 IA5String x400Address 3 EXPLICIT OR ADDRESS Type directoryName 4 EXPLICIT 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 Josefsson Expires March 5 2005 Page 6 Internet Draft Storing Certificates in the DNS September 2004 1 If a domain name is

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

  • Diff: rfc2538.txt - rfc2538xml.txt
    portion of a KEY RR before the 116 103 key tag is computed This is only possible if the key is applicable key tag is computed This is only possible if the key is applicable 117 104 to an algorithm and limits such as key size limits defined for DNS to an algorithm and limits such as key size limits defined for DNS 118 105 security If it is not the algorithm field MUST BE zero and the tag security If it is not the algorithm field MUST BE zero and the tag 119 106 field is meaningless and SHOULD BE zero field is meaningless and SHOULD BE zero 120 107 121 108 2 1 Certificate Type Values 2 1 Certificate Type Values 122 109 123 110 The following values are defined or reserved The following values are defined or reserved 124 111 125 112 Value Mnemonic Certificate Type Value Mnemonic Certificate Type 126 113 127 114 0 reserved 0 reserved 128 115 1 PKIX X 509 as per PKIX 1 PKIX X 509 as per PKIX 129 116 2 SPKI SPKI cert 2 SPKI SPKI cert 130 117 3 PGP PGP cert 3 PGP PGP cert 131 118 4 252 available for IANA assignment 4 252 available for IANA assignment 132 skipping to change at page 3 line 44 skipping to change at page 4 line 44 125 to the profile being defined by the IETF PKIX working group The to the profile being defined by the IETF PKIX working group The 139 126 certificate section will start with a one byte unsigned OID length certificate section will start with a one byte unsigned OID length 140 127 and then an X 500 OID indicating the nature of the remainder of the and then an X 500 OID indicating the nature of the remainder of the 141 128 certificate section see 2 3 below NOTE X 509 certificates do certificate section see 2 3 below NOTE X 509 certificates do 142 129 not include their X 500 directory type designating OID as a prefix not include their X 500 directory type designating OID as a prefix 143 130 144 131 The SPKI type is reserved to indicate a certificate formated as to be The SPKI type is reserved to indicate a certificate formated as to be 145 132 specified by the IETF SPKI working group specified by the IETF SPKI working group 146 133 147 134 The PGP type indicates a Pretty Good Privacy certificate as described The PGP type indicates a Pretty Good Privacy certificate as described 148 135 in RFC 2440 and its extensions and successors in 6 and its extensions and successors 149 136 150 137 The URI private type indicates a certificate format defined by an The URI private type indicates a certificate format defined by an 151 138 absolute URI The certificate portion of the CERT RR MUST begin with absolute URI The certificate portion of the CERT RR MUST begin with 152 139 a null terminated URI RFC 2396 and the data after the null is the a null terminated URI 5 and the data after the null is the private 153 140 private format certificate itself The URI SHOULD be such that a format certificate itself The URI SHOULD be such that a retrieval 154 141 retrieval from it will lead to documentation on the format of the from it will lead to documentation on the format of the certificate 155 142 certificate Recognition of private certificate types need not be Recognition of private certificate types need not be based on URI 156 143 based on URI equality but can use various forms of pattern matching equality but can use various forms of pattern matching so that for 157 144 so that for example subtype or version information can also be example subtype or version information can also be encoded into the 158 145 encoded into the URI URI 159 146 160 147 The OID private type indicates a private format certificate specified The OID private type indicates a private format certificate specified 161 148 by a an ISO OID prefix The certificate section will start with a by a an ISO OID prefix The certificate section will start with a 162 149 one byte unsigned OID length and then a BER encoded OID indicating one byte unsigned OID length and then a BER encoded OID indicating 163 150 the nature of the remainder of the certificate section This can be the nature of the remainder of the certificate section This can be 164 151 an X 509 certificate format or some other format X 509 certificates an X 509 certificate format or some other format X 509 certificates 165 152 that conform to the IETF PKIX profile SHOULD be indicated by the PKIX that conform to the IETF PKIX profile SHOULD be indicated by the PKIX 166 153 type not the OID private type Recognition of private certificate type not the OID private type Recognition of private certificate 167 154 types need not be based on OID equality but can use various forms of types need not be based on OID equality but can use various forms of 168 155 pattern matching such as OID prefix pattern matching such as OID prefix 169 156 170 157 2 2 Text Representation of CERT RRs 2 2 Text Representation of CERT RRs 171 158 172 159 The RDATA portion of a CERT RR has the type field as an unsigned The RDATA portion of a CERT RR has the type field as an unsigned 173 160 integer or as a mnemonic symbol as listed in section 2 1 above integer or as a mnemonic symbol as listed in section 2 1 above 174 161 175 162 The key tag field is represented as an unsigned integer The key tag field is represented as an unsigned integer 176 163 177 164 The algorithm field is represented as an unsigned integer or a The algorithm field is represented as an unsigned integer or a 178 165 mnemonic symbol as listed in RFC 2535 mnemonic symbol as listed in 8 179 166 180 167 The certificate CRL portion is represented in base 64 and may be The certificate CRL portion is represented in base 64 and may be 181 168 divided up into any number of white space separated substrings down divided up into any number of white space separated substrings down 182 169 to single base 64 digits which are concatenated to obtain the full to single base 64 digits which are concatenated to obtain the full 183 170 signature These substrings can span lines using the standard signature These substrings can span lines using the standard 184 171 parenthesis parenthesis 185 172 186 173 Note that the certificate CRL portion may have internal sub fields Note that the certificate CRL portion may have internal sub fields 187 174 but these do not appear in the master file representation For but these do not appear in the master file representation For 188 175 example with type 254 there will be an OID size an OID and then example with type 254 there will be an OID size an OID and then 189 176 the certificate CRL proper But only a single logical base 64 the certificate CRL proper But only a single logical base 64 190 177 string will appear in the text representation string will appear in the text representation 191 178 192 179 2 3 X 509 OIDs 2 3 X 509 OIDs 193 180 194 181 OIDs have been defined in connection with the X 500 directory for OIDs have been defined in connection with the X 500 directory for 195 182 user certificates certification authority certificates revocations user certificates certification authority certificates revocations 196 183 of certification authority and revocations of user certificates of certification authority and revocations of user certificates 197 184 The following table lists the OIDs their BER encoding and their The following table lists the OIDs their BER encoding and their 198 185 length prefixed hex format for use in CERT RRs length prefixed hex format for use in CERT RRs 199 186 200 187 id at userCertificate id at userCertificate 201 188 joint iso ccitt 2 ds 5 at 4 36 joint iso ccitt 2 ds 5 at 4 36 202 189 0x 03 55 04 24 0x 03 55 04 24 203 skipping to change at page 5 line 31 skipping to change at page 6 line 31 203 name related to their subject i e the name of the entity intended name related to their subject i e the name of the entity intended 217 204 to control the private key corresponding to the public key being to control the private key corresponding to the public key being 218 205 certified It is recommended that certificate revocation list CERT certified It is recommended that certificate revocation list CERT 219 206 RRs be stored under a domain name related to their issuer RRs be stored under a domain name related to their issuer 220 207 221 208 Following some of the guidelines below may result in the use in DNS Following some of the guidelines below may result in the use in DNS 222 209 names of characters that require DNS quoting which is to use a names of characters that require DNS quoting which is to use a 223 210 backslash followed by the octal representation of the ASCII code for backslash followed by the octal representation of the ASCII code for 224 211 the character such as 000 for NULL the character such as 000 for NULL 225 212 226 213 3 1 X 509 CERT RR Names 3 1 X 509 CERT RR Names 227 214 228 215 Some X 509 versions permit multiple names to be associated with Some X 509 versions permit multiple names to be associated with 229 216 subjects and issuers under Subject Alternate Name and Issuer subjects and issuers under Subject Alternate Name and Issuer 230 217 Alternate Name For example x 509v3 has such Alternate Names with Alternate Name For example x 509v3 has such Alternate Names with 231 218 an ASN 1 specification as follows an ASN 1 specification as follows 232 219 233 220 GeneralName CHOICE GeneralName CHOICE 234 221 otherName 0 INSTANCE OF OTHER NAME otherName 0 INSTANCE OF OTHER NAME 235 222 rfc822Name 1 IA5String rfc822Name 1 IA5String 236 223 dNSName 2 IA5String dNSName 2 IA5String 237 skipping to change at page 6 line 5 skipping to change at page 7 line 5 225 directoryName 4 EXPLICIT Name directoryName 4 EXPLICIT Name 239 226 ediPartyName 5 EDIPartyName ediPartyName 5 EDIPartyName 240 227 uniformResourceIdentifier 6 IA5String uniformResourceIdentifier 6 IA5String 241 228 iPAddress 7 OCTET STRING iPAddress 7 OCTET STRING 242 229 registeredID 8 OBJECT IDENTIFIER registeredID 8 OBJECT IDENTIFIER 243 230 244 231 245 232 The recommended locations of CERT storage are as follows in priority The recommended locations of CERT storage are as follows in priority 246 233 order order 247 234 248 235 1 If a domain name is included in the identification in the 1 If a domain name is included in the identification in the 249 236 certificate or CRL that should be used certificate or CRL that should be used 250 237 2 If a domain name is not included but an IP address is included 2 If a domain name is not included but an IP address is included 251 238 then the translation of that IP address into the appropriate then the translation of that IP address into the appropriate 252 239 inverse domain name should be used inverse domain name should be used 253 240 3 If neither of the above it used but a URI containing a domain 3 If neither of the above it used but a URI containing a domain 254 241 name is present that domain name should be used name is present that domain name should be used 255 242 4 If none of the above is included but a character string name is 4 If none of the above is included but a character string name is 256 243 included then it should be treated as described for PGP names in included then it should be treated as described for PGP names in 257 244 3 2 below 3 2 below 258 245 5 If none of the above apply then the distinguished name DN 5 If none of the above apply then the distinguished name DN 259 246 should be mapped into a domain name as specified in RFC 2247 should be mapped into a domain name as specified in 4 260 247 261 248 Example 1 Assume that an X 509v3 certificate is issued to CN John Example 1 Assume that an X 509v3 certificate is issued to CN John 262 249 Doe DC Doe DC com DC xy O Doe Inc C XY with Subject Alternative Doe DC Doe DC com DC xy O Doe Inc C XY with Subject Alternative 263 250 names of a string John the Man Doe b domain name john names of a string John the Man Doe b domain name john 264 251 doe com and c uri https www secure john doe com 8080 Then doe com and c uri https www secure john doe com 8080 Then 265 252 the storage locations recommended in priority order would be the storage locations recommended in priority order would be 266 253 1 john doe com 1 john doe com 267 254 2 www secure john doe com and 2 www secure john doe com and 268 255 3 Doe com xy 3 Doe com xy 269 256 270 257 Example 2 Assume that an X 509v3 certificate is issued to CN James Example 2 Assume that an X 509v3 certificate is issued to CN James 271 258 Hacker L Basingstoke O Widget Inc C GB with Subject Alternate names Hacker L Basingstoke O Widget Inc C GB with Subject Alternate names 272 259 of a domain name widget foo example b IPv4 address of a domain name widget foo example b IPv4 address 273 260 10 251 13 201 and c string James Hacker 10 251 13 201 and c string James Hacker 274 261 hacker mail widget foo example Then the storage locations hacker mail widget foo example Then the storage locations 275 262 recommended in priority order would be recommended in priority order would be 276 263 1 widget foo example 1 widget foo example 277 264 2 201 13 251 10 in addr arpa and 2 201 13 251 10 in addr arpa and 278 265 3 hacker mail widget foo example 3 hacker mail widget foo example 279 266 280 267 3 2 PGP CERT RR Names 3 2 PGP CERT RR Names 281 268 282 269 PGP signed keys certificates use a general character string User ID PGP signed keys certificates use a general character string User ID 283 270 RFC 2440 However it is recommended by PGP that such names include 6 However it is recommended by PGP that such names include the 284 271 the RFC 822 email address of the party as in Leslie Example RFC 822 email address of the party as in Leslie Example 285 272 Leslie host example If such a format is used the CERT should be Leslie host example If such a format is used the CERT should be 286 273 under the standard translation of the email address into a domain under the standard translation of the email address into a domain 287 274 name which would be leslie host example in this case If no RFC 822 name which would be leslie host example in this case If no RFC 822 288 275 name can be extracted from the string name no specific domain name is name can be extracted from the string name no specific domain name is 289 276 recommended recommended 290 277 291 278 4 Performance Considerations 4 Performance Considerations 292 279 293 280 Current Domain Name System DNS implementations are optimized for Current Domain Name System DNS implementations are optimized for 294 281 small transfers typically not more than 512 bytes including small transfers typically not more than 512 bytes including 295 skipping to change at page 7 line 14 skipping to change at page 8 line 15 283 underway to make larger transfers more efficient it is still underway to make larger transfers more efficient it is still 297 284 advisable at this time to make every reasonable effort to minimize advisable at this time to make every reasonable effort to minimize 298 285 the size of certificates stored within the DNS Steps that can be the size of certificates stored within the DNS Steps that can be 299 286 taken may include using the fewest possible optional or extensions taken may include using the fewest possible optional or extensions 300 287 fields and using short field values for variable length fields that fields and using short field values for variable length fields that 301 288 must be included must be included 302 289 303 290 5 IANA Considerations 5 IANA Considerations 304 291 305 292 Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can 306 293 only be assigned by an IETF standards action RFC 2434 and this only be assigned by an IETF standards action 7 and this document 307 294 document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE Certificate 308 295 Certificate types 0x0100 through 0xFEFF are assigned through IETF types 0x0100 through 0xFEFF are assigned through IETF Consensus 7 309 296 Consensus RFC 2434 based on RFC documentation of the certificate based on RFC documentation of the certificate type The availability 310 297 type The availability

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


  • OID length and then a BER encoded OID indicating the nature of the remainder of the certificate section This can be an X 509 certificate format or some other format X 509 certificates that conform to the IETF PKIX profile SHOULD be indicated by the PKIX type not the OID private type Recognition of private certificate types need not be based on OID equality but can use various forms of pattern matching such as OID prefix 2 2 Text Representation of CERT RRs The RDATA portion of a CERT RR has the type field as an unsigned decimal integer or as a mnemonic symbol as listed in section 2 1 above The key tag field is represented as an unsigned decimal integer The algorithm field is represented as an unsigned decimal integer or a mnemonic symbol as listed in 10 The certificate CRL portion is represented in base 64 8 and may be divided up into any number of white space separated substrings down to single base 64 digits which are concatenated to obtain the full signature These substrings can span lines using the standard parenthesis Note that the certificate CRL portion may have internal sub fields but these do not appear in the master file representation For example with type 254 there will be an OID size an OID and then the certificate CRL proper But only a single logical base 64 string will appear in the text representation 2 3 X 509 OIDs OIDs have been defined in connection with the X 500 directory for user certificates certification authority certificates revocations of certification authority and revocations of user certificates The following table lists the OIDs their BER encoding and their Josefsson Expires April 14 2005 Page 5 Internet Draft Storing Certificates in the DNS October 2004 length prefixed hex format for use in CERT RRs id at userCertificate joint iso ccitt 2 ds 5 at 4 36 0x 03 55 04 24 id at cACertificate joint iso ccitt 2 ds 5 at 4 37 0x 03 55 04 25 id at authorityRevocationList joint iso ccitt 2 ds 5 at 4 38 0x 03 55 04 26 id at certificateRevocationList joint iso ccitt 2 ds 5 at 4 39 0x 03 55 04 27 3 Appropriate Owner Names for CERT RRs It is recommended that certificate CERT RRs be stored under a domain name related to their subject i e the name of the entity intended to control the private key corresponding to the public key being certified It is recommended that certificate revocation list CERT RRs be stored under a domain name related to their issuer Following some of the guidelines below may result in the use in DNS names of characters that require DNS quoting which is to use a backslash followed by the octal representation of the ASCII code for the character such as 000 for NULL 3 1 X 509 CERT RR Names Some X 509 versions permit multiple names to be associated with subjects and issuers under Subject Alternate Name and Issuer Alternate Name For example x 509v3 has such Alternate Names with an ASN 1 specification as follows GeneralName CHOICE otherName 0 INSTANCE OF OTHER NAME rfc822Name 1 IA5String dNSName 2 IA5String x400Address 3 EXPLICIT OR ADDRESS Type directoryName 4 EXPLICIT Name ediPartyName 5 EDIPartyName uniformResourceIdentifier 6 IA5String iPAddress 7 OCTET STRING registeredID 8 OBJECT IDENTIFIER Josefsson Expires April 14 2005 Page 6 Internet Draft Storing Certificates in the DNS October 2004 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 should 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 should be used 3 If neither of the above it used but a URI containing a domain name is present that domain name should be used 4 If none of the above is included but a character string name is included then it should be treated as described for PGP names in 3 2 below 5 If none of the above apply then the distinguished name DN should be mapped into a domain name as specified in 3 Example 1 Assume that 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 Then the storage locations recommended in priority order would be 1 john doe com 2 www secure john doe com and 3 Doe com xy Example 2 Assume that 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 Then 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 PGP CERT RR Names OpenPGP signed keys certificates use a general character string User ID 5 However it is recommended by PGP 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 should be under the standard translation of the email address into 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 Josefsson Expires April 14 2005 Page 7 Internet Draft Storing Certificates in the DNS October 2004 ORIGIN example org smith IN CERT PGP 0 0

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



  •