{"action":"created","issue":{"url":"https://api.github.com/repos/letsencrypt/boulder/issues/2093","repository_url":"https://api.github.com/repos/letsencrypt/boulder","labels_url":"https://api.github.com/repos/letsencrypt/boulder/issues/2093/labels{/name}","comments_url":"https://api.github.com/repos/letsencrypt/boulder/issues/2093/comments","events_url":"https://api.github.com/repos/letsencrypt/boulder/issues/2093/events","html_url":"https://github.com/letsencrypt/boulder/issues/2093","id":168391162,"number":2093,"title":"Improve RFC 5280 compliance in regards to subject and SAN","user":{"login":"benileo","id":5097742,"avatar_url":"https://avatars.githubusercontent.com/u/5097742?v=3","gravatar_id":"","url":"https://api.github.com/users/benileo","html_url":"https://github.com/benileo","followers_url":"https://api.github.com/users/benileo/followers","following_url":"https://api.github.com/users/benileo/following{/other_user}","gists_url":"https://api.github.com/users/benileo/gists{/gist_id}","starred_url":"https://api.github.com/users/benileo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benileo/subscriptions","organizations_url":"https://api.github.com/users/benileo/orgs","repos_url":"https://api.github.com/users/benileo/repos","events_url":"https://api.github.com/users/benileo/events{/privacy}","received_events_url":"https://api.github.com/users/benileo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-07-29T18:57:42Z","updated_at":"2016-08-08T22:15:40Z","closed_at":null,"body":"Boulder currently uses CN=[domain-name] as a distinguished name in a subjects certificate. This may not be the ideal implementation based on the following:\r\n\r\nFrom section 4.1.2.4. in RFC 5280 on subject\r\n> In addition, implementations of this specification MUST be prepared\r\n>    to receive the domainComponent attribute, as defined in [RFC4519].\r\n>    The Domain Name System (DNS) provides a hierarchical resource\r\n>    labeling system.  This attribute provides a convenient mechanism for\r\n>    organizations that wish to use DNs that parallel their DNS names.\r\n>    This is not a replacement for the dNSName component of the\r\n>    alternative name extensions.\r\n\r\nFurthermore, from section 4.2.1.6. on Subject Alternative Name\r\n> Whenever such identities are to be bound into a\r\n>    certificate, the subject alternative name (or issuer alternative\r\n>    name) extension MUST be used; however, a DNS name MAY also be\r\n>    represented in the subject field using the **domainComponent** attribute\r\n\r\nAlso from 4.2.1.6. \r\n> If the subject field\r\n>    contains an empty sequence, then the issuing CA MUST include a\r\n>    subjectAltName extension that is marked as critical.  When including\r\n>    the subjectAltName extension in a certificate that has a non-empty\r\n>    subject distinguished name, conforming CAs SHOULD mark the\r\n>    subjectAltName extension as **non-critical.**\r\n> \r\n\r\nI propose boulder use one of the following:\r\n\r\n1. Drop CN=[domain-name] and have the certificates subject be empty and use SAN only, and mark the extension as critical\r\n2. Drop CN=[domain-name] and instead use DC=[domain-name]. This will result in the SAN be marked as non critical and better compliance with RFC 5280. This may not be possible until https://github.com/cloudflare/cfssl/issues/632 is resolved."},"comment":{"url":"https://api.github.com/repos/letsencrypt/boulder/issues/comments/238394654","html_url":"https://github.com/letsencrypt/boulder/issues/2093#issuecomment-238394654","issue_url":"https://api.github.com/repos/letsencrypt/boulder/issues/2093","id":238394654,"user":{"login":"jsha","id":220205,"avatar_url":"https://avatars.githubusercontent.com/u/220205?v=3","gravatar_id":"","url":"https://api.github.com/users/jsha","html_url":"https://github.com/jsha","followers_url":"https://api.github.com/users/jsha/followers","following_url":"https://api.github.com/users/jsha/following{/other_user}","gists_url":"https://api.github.com/users/jsha/gists{/gist_id}","starred_url":"https://api.github.com/users/jsha/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jsha/subscriptions","organizations_url":"https://api.github.com/users/jsha/orgs","repos_url":"https://api.github.com/users/jsha/repos","events_url":"https://api.github.com/users/jsha/events{/privacy}","received_events_url":"https://api.github.com/users/jsha/received_events","type":"User","site_admin":false},"created_at":"2016-08-08T22:15:40Z","updated_at":"2016-08-08T22:15:40Z","body":"> Drop CN=[domain-name] and have the certificates subject be empty and use SAN only, and mark the extension as critical\r\n\r\nI have heard that empty subjects / critical SANs have compatibility problems. I haven't dug into the details myself, but this is probably not the right approach.\r\n\r\n> Drop CN=[domain-name] and instead use DC=[domain-name]. This will result in the SAN be marked as non critical and better compliance with RFC 5280. This may not be possible until cloudflare/cfssl#632 is resolved.\r\n\r\nThis might be a good approach! We've been thinking of doing something along these lines, but using domainComponent may make more sense. Need to read the docs a bit more and do some testing."}}
{"actor":{"display_login":"jsha"}}