Here is my tags proposal, in case others want to = comment on it on this list.

Note = that it has been privately pointed out to me that one possible solution = to the criticality problem and the scaling problem is to use top-level = tags that are independent of the issue records:

Something like:

CAA 0 = issue “a.example.com”

CAA = 0 issue “b.example.com”

CAA 128 validation = “Phone”

-Tim

----------------------------------------------------= -------------------------------------------------------------------------= --------------------------

Introduction and = Motivation

In addition to being able to specify which CA or CAs = are allowed to issue certificates for a given domain, RFC 6844 allows = additional parameters, such as the account number, that the CA can = consume for a variety of uses. RFC 6844 defines the format, but = otherwise leaves the kinds of properties and their meanings up to the = issuer.

While this is appropriate for = a technical standard, standardizing the names and meanings of CAA = properties across the CA industry has the following = benefits:

Reduce user confusion when the same or similar property is used by = different CAs with different names and semantics
Make it simpler to migrate from one CA to another while preserving = the CAA configuration
Simplifying configuration and expression of CAA policies that = allow issuance from multiple CAs
Allow CAA record creation tools to support creating CAA records = that contain properties that have been = standardized

History

CAA property = tags have been discussed at several CA/B Forum meetings, most recently = at the October meeting in Taipei. Four were suggested: Acceptable = validation methods, an account identifier, certificate types (DV/OV/EV), = and ability to specify a brand.

Method of = Adoption

Since these CAA properties are just a voluntary = industry standard that any CA could implement, they don’t = necessarily have to exist in a standards document. However, it = seems like it would be helpful if the names and semantics were agreed = upon by the industry as a whole, so it is probably best to include them = in the Baseline Requirements as an optional feature CAs MAY = implement.

On the other hand, it = might be desirable to reserve the names, and require that if these = particular property names are used, the semantics MUST be the semantics = specified in the Baseline Requirements.

Brands

I’m = starting with this one because I’m going to argue it isn’t = necessary. CAs can and do have multiple names that they accept in = CAA records. It is hard to imagine a brand existing without the = associated domain and website also existing. I’d suggest = that CAs that maintain multiple brands simply use a different domain = name for each brand, e.g.

certs.example.com &n= bsp; CAA 0 issue = “megaca.com”

catlover.example.com = ; CAA 0 issue = “certsforcats.com” # certsforcats is a = brand owned by MegaCA.

CAAs can also = publicize examples of CAA records that allow for issuance by all of = their brands.

Acceptable Validation = Methods

A list of acceptable validation methods can be = specified using the “validation” tag.

There are two challenges here, that have been = discussed elsewhere in relation to keeping records of which validation = method was used for a particular certificate. The first is that = validation methods can change over time. This seems to be less of = a concern for issuance than it is for historical validations, as a CAA = record can and should be interpreted as always requiring the version of = the method that is enforced by the BRs at issuance time. However, = this can cause the exact meaning of a CAA record to change over time as = the BRs evolve. I don’t think this is a big problem, but = wanted to note it.

The second issue = is that it is possible that the numbering of the BR validation methods = could potentially change over time. For that reason, I think it = might be reasonable to standardize on a label for each validation = method, that can be used in addition to the section = number:

Examples:

CAA 0 = issue “ca.example.net; = validation=3D3” &nbs= p; = ; # Call me about all certificates

CAA 0 issue “ca.example.net; = validation=3DPhone” = # Same as previous example

CAA 0 issue “ca.example.net; = validation=3D1,2,3,4,7,8,9,10” # I don’t like = DADs and website changes

CAA 0 issue = “ca.example.net; = validation=3D!5,6” &= nbsp; # Same as previous = example. Worth the trouble?

Account = Identifier

This one is relatively straightforward, as the = identifier is going to be CA-specific anyway. Use the = “account” keyword:

CAA 0 = issue “ca.example.net; account=3D8675309”

The format and values of the account specifier is up = to the individual CA.

Acceptable Certificate = Types

This one also seems to be relatively = straightforward. I’ve chosen to make the categories = disjoint, so if you’re ok with more than one type, you have to = specify more than one. Use the “type” = keyword.

CAA 0 issue = “ca.example.net; = type=3DEV” &nb= sp; &nbs= p; # EV only

CAA 0 issue = “ca.example.net; = type=3DDV” &nb= sp; &nbs= p; # DV only

CAA 0 issue = “ca.example.net; = type=3DOV,EV” = # No = DV

Lack of Property Tag Value = Criticality

Supporting the various properties is optional. = Unlike the CAA “issue” property, these properties do not = have to be ubiquitously supported to have value, because Domain holders = can restrict their issue records to only include CAs that have publicly = stated that they support the desired property tags.

For example, if CAs A, B, and C support the = “type=3DEV” tag, then the following will prevent non-EV = issuance:

CAA issue 0 “A.com; = type=3DEV”

CAA issue 0 = “B.com; type=3DEV”

CAA = issue 0 “C.com; type=3DEV”

Unfortunately, this does scale poorly with a large = number of CAs.

The problem is that = RFC 6844 supports “Critical” for property tags (like = “issue”), but there is no way to mark a parameter tag is = “Critical”. I intend to bring this up with the IETF = WG.

Any easy solution is to use = reserved bit #1 for property tag criticality:

CAA issue 64 “A.com; = type=3DEV” &nb= sp; # type=3DEV tag must be = respected;
= ; = &= nbsp; &n= bsp; &nb= sp; # cannot issue if = you don’t understand or enforce it.

Multiple = Tags

Just for completeness, these individual features can = also be used together:

CAA issue 0 = “ca.example.com; type=3DEV validation=3DPhone = account=3D8675309”

------=_NextPart_001_0523_01D377EC.C88FF0A0-- ------=_NextPart_000_0522_01D377EC.C88FF0A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMjE4MTc0MTM4WjAvBgkqhkiG9w0BCQQxIgQgq88Eq5uHjpuVf6fHZVJl/frs3iYR vJ7W5pG8OJ5Dqw4wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHOTdUNZfSdPtabKveKXlxM2DxA8OZkxZBnRSYMANy2qaKAAeCWFfHDxry+wuvcSh31mKXxU E+I3bzrWKMH09fidHsq0DtPm+I9WYDTY3ko/RFUbCHK0aQl4tpqGdybMWK4z+J+JZub0P4rCiY8N 2NBDHnny6pJKZzvXDxQR5i1mXCkPlNfwtSfYUMVrBczqbq/o9Pald58V7wcG1iz67fM+TzjREIpE EVpJG00vzelXxyQr/91PND/XR4wU8WUNlaoN9RTxmSlSIoVdEGBlXi6tN2RP0TVnVlc3Ikd5S3US lUBCNwJqS3WHGmViIBFWnCLie1MMutiEg6pKS2BiMjwAAAAAAAA= ------=_NextPart_000_0522_01D377EC.C88FF0A0-- From nobody Mon Dec 18 11:30:46 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E47B126C83 for ; Mon, 18 Dec 2017 11:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.111 X-Spam-Level: X-Spam-Status: No, score=-5.111 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGSOrHbZqhxp for ; Mon, 18 Dec 2017 11:30:42 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B7C120454 for ; Mon, 18 Dec 2017 11:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=RWHji3OQbAeL5/wvN8DBigj9MCpcgEcD8fncVa5sNpc=; b=s62jNtCoZNsXez/YhO7dHP9ktqKHpX7urWuvdJe324xZQm+rm2e1el+xx2BhmwCzBIuZAir+V14qGf9rSZ+NI/QthdZv4iELRLWAMJ7x0NkCfni6coJXwM6ZkkyfRWiIfRc3OjkiL3WDIyyRLVFWpyXvBQGZIBs1QOmPmbh8EMA=; Received: ; Mon, 18 Dec 2017 11:30:37 -0800 To: spasm@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org> Date: Mon, 18 Dec 2017 11:30:40 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] CAA tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:30:45 -0000 I'm following up your the related validation@cabforum thread at https://cabforum.org/pipermail/validation/2017-December/000686.html, hoping to merge the streams a little bit. :-) On 12/18/2017 11:10 AM, Tim Hollebeek via Validation wrote: > I personally find OIDs very hard for non-technical users to grasp. This is a good point, although most users should be using a CAA record generator, which can help with this. > readable text labels, like Validation=Phone? My issue with validation=phone is that it is not precise enough; there's one version of validation by phone defined in the BRs today, but what if that changes significantly? One could solve this by defining a versioned validation method, e.g. validation=phone-01, with an IANA registry to register new ones as requirements change. However, there does seem to be some interest in embedding information about validation methods in certificates. It would be nice if there was a correspondence between the namespace used in CAA and the one used in certificates. > I think account and account-uri are complimentary approaches. I agree > that CAs need the freedom to put whatever they want on the right hand > side of these, and many CAs have existing customer identification > schemes that are not URIs, so the account-uri field cannot be used. It's easy to define a URI mapping for an existing account identifier. For instance, if customers have a numeric id 123456, the CA can specify that the corresponding account-uri is https://ca.example.net/accounts/123456. There's no requirement that account-uris are fetchable. It seems inefficient to define the same mechanism under two different names in two different places (account vs account-uri), and I think is likely to lead to user error. From nobody Mon Dec 18 12:11:00 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0616012420B for ; Mon, 18 Dec 2017 12:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYM7S9ZdfiQ9 for ; Mon, 18 Dec 2017 12:10:57 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843261205D3 for ; Mon, 18 Dec 2017 12:10:57 -0800 (PST) Received: from [216.82.249.212] by server-17.bemta-12.messagelabs.com id E0/C0-10763-0D0283A5; Mon, 18 Dec 2017 20:10:56 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSf0yMcRzH7/v8uB50PF2lj1s/uDLUOpIfR5s ZVg1tmB85WT3VU3dzd+V5jsUfZMZwhqZwLdXGYg2bREaFk+SySZckGRHyWypkae657xX+e30/ 7/f3+/58P/swpNIpVzF8joUXzJxRLR9NPdCc2hrZNFGrm/HuGa21tQzItcWtaQuJ+M/f3tLxp 08PECsIHW0wp2blpND6YutZlH0lNsf2YmUuerPoABrNUOwXAkqfN5LSQcnmE1Db00UcQKNchz oExUeRxHJ2BrTW3HXX/dhl0HqhQC6xLxsEnR3XSVwPhtJb/TTm+VCb53AzxU4GR2sNJbGCTYJ LpZ8JHHYQQVtfuTtgFBsD1Van24TY8fDDcc4dRrIB0N5V4mZg/aDzYaMcsz+8ezVEY38SnOy1 e+pqeHr+J8IcBM0lViSFAWv3gra3ZV5Y0MDlvE8eUwL01u+msakMwffXj0kshEODfa/HtAkcF zu9huv76goJfOE2CXt+V3pMgfCqzkphoYKGw49f03iQ6ZBfbvcMTAXPWvYjzIHQ3VFDH0FTC/ /5aqHrPsmWuGZvO04VuofmA/dsXRQ2RcK12psk5hCo+lTk4Rg48euWHPMkyLd2emGeDR/u9KB SxJSjqSIvbOWFyGitJlUwZOotJs5gjIyKmqkx8aLIZfJGLlXUpGWZKpBrtXbKZOgq6r6xwY4m MITaX2EbM0enHJualb5Nz4n6ZGGLkRftKJBh1KAQQrQ6pY/AZ/I5GQajaz+HZWC81X6KaZKsE LM5k2jIxJIDRTOD1e2DBPPG9iGXVFLmLDOvClDskqysZNVvMY88NLzrzShI5atAMplM6Z3NCy aD5X/9PQpgkNpXcVF6xdtgtozkvXe1QrhaKUicK7Vi4f5Kqlw0PSHszP1V3+OSI+KqQx6t67h 80hnet3JsSlrskmDON/TJUHpKhVHVsn6ZLqF/IHrc1YyI+K+rme03Nn9UFVUmP01Y3DauZy3q XuAd25C2dMesS/1TasJeNs0xEjMdBf7zdq7ZmNibXx/V0FeVvSfuelfVod2JZcWhxOQJ7csnV TiPOZPUlKjnosJJQeT+ANKbBSzmAwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-219.messagelabs.com!1513627855!200252163!1 X-Originating-IP: [207.46.163.118] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20888 invoked from network); 18 Dec 2017 20:10:55 -0000 Received: from mail-sn1nam01lp0118.outbound.protection.outlook.com (HELO NAM01-SN1-obe.outbound.protection.outlook.com) (207.46.163.118) by server-8.tower-219.messagelabs.com with AES256-SHA256 encrypted SMTP; 18 Dec 2017 20:10:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HsxzHPCCn8k0jthRPFw9G6SehKi/Rpc3e8wj2bxsGDc=; b=RCrCRgH1+jPbh8GUQNqnJrF3d+F+h8xQFxQJPNt3hKiO/d67Rl0gIzg5Vn0nuSbdga5uHx883Zb32hHWWoZklOimkTyh//5x1kisSTsljDvKclzacnFbhlKwF9lHoRVGUpLXNGJWAU5Ya5a2RRK4xQK2ROE2sUvOZSVLm1oqPCo= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Mon, 18 Dec 2017 20:10:54 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0323.018; Mon, 18 Dec 2017 20:10:53 +0000 From: Tim Hollebeek To: Jacob Hoffman-Andrews , "spasm@ietf.org" Thread-Topic: [lamps] CAA tags Thread-Index: AdN4J3TZ60fppeKgRNaOHREkYP39nwADzsgAAAD5epA= Date: Mon, 18 Dec 2017 20:10:53 +0000 Message-ID: References: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org> In-Reply-To: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1289; 6:oqr8DGCFmiKGqS9paazg5TqDYGfxPSfhItGcrGwQVSGl6baco57GtkZJwn0h+qShnovePaM0LxW5dNkzfgp31ms9QnEqt5IloxteMwVPTUHBC5S2GDlgH64XU4xOHsGzvgM6/lSiQ3LJ9QpPMU1Cc3TLjO7vEYFwUzDimDWnWyllbUA03S2UhEjxG/k9dN8zdkanzcZ0xOE7F2O9Y807Cb+7/n8GX75Qk3c0k4X0NDHue41qFadiItdSyoPswHLGKQJHr+uQB6H/4rjbfa3Icz4rzHC2h4sG82440Jk3ohr34q/cAzgt8bbYCe2RPtqq8dgjK3S6ui25M+A+D8ODxv/Kob6yoQFFvKlJ+FLuOQI=; 5:vp4EvnpBEKbOLWN0msZ9JyIDnawDyhhvfbcGRSTPGjk9Eqevc4MMI/y0ORuhzC3lwzbpz7nWr2jJPBYKJfuU9fySSCeUG5KAFpUK98bYgrxjw1L35l8TyKU2wkLAynG1n1r61HFPc445Sz1nXeCmGK9256370OMc4QKhwMDeRw4=; 24:X5rMyqtPRKMvM3KTOWDxN/lyvwqtSwDqjzGgBCkDo5nGUGZozLuyzKBmP8KRGGL6q2N/7WKL3Qlo0NqZRBQOm3nbGjDeM4I4RAu4IV8WuoA=; 7:gaKbE9q7LzYXNApRUyleYpBDLJagrH4+pIH9AoOAcIwx0NTzmJKyCKHQM4BW2xrcW2Isfa8FogqgtegO0Cg0lSFxmrxBwiHfc8ixYEz3OLM34x34UOVI92nK230BcEOPB6ezIw6pvA4Q9cxYcuzq8V9SSRkl2BKaIo+Nc5gst2M8MxNArYymBdpa4W17u6qU83qVIRsLukTKNSkuGfesjidc4k779qT1Poic1aN6qkjia27iDuskk8ace+uqUJso x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d8391c76-d36f-4ab5-e295-08d54653714d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307)(49563074); SRVR:DM5PR14MB1289; x-ms-traffictypediagnostic: DM5PR14MB1289: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231023)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:DM5PR14MB1289; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1289; x-forefront-prvs: 0525BB0ADF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(39860400002)(376002)(189003)(199004)(3660700001)(6246003)(105586002)(305945005)(9686003)(110136005)(6306002)(106356001)(55016002)(8676002)(7736002)(53936002)(68736007)(316002)(2906002)(86362001)(81156014)(3280700002)(81166006)(6116002)(99936001)(33656002)(8936002)(3846002)(102836003)(66066001)(74316002)(99286004)(2950100002)(2900100001)(966005)(14454004)(6506007)(77096006)(97736004)(7696005)(2501003)(5660300001)(25786009)(76176011)(59450400001)(6436002)(229853002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1289; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0589_01D37801.9DE446C0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8391c76-d36f-4ab5-e295-08d54653714d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 20:10:53.8546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1289 Archived-At: Subject: Re: [lamps] CAA tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:10:59 -0000 ------=_NextPart_000_0589_01D37801.9DE446C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > readable text labels, like Validation=Phone? > > My issue with validation=phone is that it is not precise enough; there's one > version of validation by phone defined in the BRs today, but what if that > changes significantly? One could solve this by defining a versioned validation > method, e.g. validation=phone-01, with an IANA registry to register new ones > as requirements change. The lack of precision bothered me a bit too when I was proposing it, especially since some people have discussed breaking up some of the larger catch-all ones. I like the version number, but I think we have to be a bit careful. Is the version just a minimum version? If I have CAA set to validation=phone-01, do I have to update my CAA record every time the BR validation methods are changed? How big of a change requires revving the version number of the validation method? Should the BR version number be used instead? E.g. validation=phone-1.5.4? This might make more sense as the BR version number does get bumped on every validation rev (and non-validation rev ...). > However, there does seem to be some interest in embedding information > about validation methods in certificates. It would be nice if there was a > correspondence between the namespace used in CAA and the one used in > certificates. That would be nice. Maybe an IANA registry for validation methods might make sense, but I'm unfamiliar with how easy/difficult that is to set up/ modify. > It's easy to define a URI mapping for an existing account identifier. > For instance, if customers have a numeric id 123456, the CA can specify that > the corresponding account-uri is https://ca.example.net/accounts/123456. > There's no requirement that account-uris are fetchable. I get that, but a URI is longer and more complicated. Quirin's research shows that a significant fraction of CAA users CANNOT SPELL THEIR CA'S NAME. I shudder to think how they will manage to mangle a URI ... -Tim ------=_NextPart_000_0589_01D37801.9DE446C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMjE4MjAxMDQ2WjAvBgkqhkiG9w0BCQQxIgQgRxSFsgOtP+cTc2duNTIM3fUMFMsW aYl973FijenSGGUwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBALvbYM7czPwvkx0zMvZTMyE677Q6/TOz/ZpEOIGGfD0VTApW8LL+cigda0KYjkBpOdPpim53 KvfLlngdficvlaJyKqaQ8QXh+O29+CSqYU2g8qjKL+JrGNDmcDa9qqjmo+Hc0v4dSRKRDZgq0rfj RTIvVLfXSoCrAfsS2hCdSkFCQgHH5NBM5yXnnlH0bajopxobYzZfGnVZiiH774EeXKdFNpwDAti5 gncAuxiTmkJahUM074zfJxDgd6g4I1vM1ie4vKzuQDpF/fap7cB34dAlXUFK6yI2jDOOQHpMVKDl Uu4AAAdn44RI/lx71THcYTsbXPaqjq9jmDW9G5nwAV8AAAAAAAA= ------=_NextPart_000_0589_01D37801.9DE446C0-- From nobody Mon Dec 18 12:42:10 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AA312D851 for ; Mon, 18 Dec 2017 12:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Soz4G-02gWnu for ; Mon, 18 Dec 2017 12:42:07 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E25C1200FC for ; Mon, 18 Dec 2017 12:42:07 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 05F263C001C17 for ; Mon, 18 Dec 2017 12:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=SkiWCfGo3CcseF/w6fp9l0tv4sE=; b= PgMu9ddJFt67zUop3EMFk3o/sYhDXBzJum1/lVMaNWazHi8nM9CaFGg8w/ZRrbjJ jUX70b9QhM26ArtoqZs4YI7RFe9XoDDQK+d0HY63TO6ZAoZJMa4IUGDFriJQ6Lsz oMtJmdTll7MoYYKZFL6bRZPuJxy7/UV/DexbSeXaL6M= Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id E02DF3C001C18 for ; Mon, 18 Dec 2017 12:42:06 -0800 (PST) Received: by mail-it0-f46.google.com with SMTP id p139so240008itb.1 for ; Mon, 18 Dec 2017 12:42:06 -0800 (PST) X-Gm-Message-State: AKGB3mLGCfnyFVtBOkZhMsOOMbRM/K2g0hLx8nAS2l/xw5zdJiOqS0lh +qmqeOOfk1WXGLXCtV8cHRr1CM4fORDTSp2HDzI= X-Google-Smtp-Source: ACJfBot9+h/+72ollqG23UJ07CrSEVehg16KQgjrRGzXyE7xkOQltun1iaM0heFn/GZ2SBws/XayvtJUbPiL/xO/jYo= X-Received: by 10.36.61.149 with SMTP id n143mr459320itn.67.1513629726159; Mon, 18 Dec 2017 12:42:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.78.70 with HTTP; Mon, 18 Dec 2017 12:42:05 -0800 (PST) In-Reply-To: References: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org> From: Ryan Sleevi Date: Mon, 18 Dec 2017 15:42:05 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Tim Hollebeek Cc: Jacob Hoffman-Andrews , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="001a1144452e2645c10560a36229" Archived-At: Subject: Re: [lamps] CAA tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:42:09 -0000 --001a1144452e2645c10560a36229 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 18, 2017 at 3:10 PM, Tim Hollebeek wrote: > > > > > readable text labels, like Validation=Phone? > > > > My issue with validation=phone is that it is not precise enough; there's > one > > version of validation by phone defined in the BRs today, but what if that > > changes significantly? One could solve this by defining a versioned > validation > > method, e.g. validation=phone-01, with an IANA registry to register new > ones > > as requirements change. > > The lack of precision bothered me a bit too when I was proposing it, > especially since some people have discussed breaking up some of the > larger catch-all ones. I like the version number, but I think we have to > be > > a bit careful. Is the version just a minimum version? If I have CAA set > to > > validation=phone-01, do I have to update my CAA record every time the > BR validation methods are changed? How big of a change requires revving > the version number of the validation method? > > Should the BR version number be used instead? E.g. validation=phone-1.5.4? > This might make more sense as the BR version number does get bumped on > every validation rev (and non-validation rev ...). > > > However, there does seem to be some interest in embedding information > > about validation methods in certificates. It would be nice if there was a > > correspondence between the namespace used in CAA and the one used in > > certificates. > > That would be nice. Maybe an IANA registry for validation methods might > make sense, but I'm unfamiliar with how easy/difficult that is to set up/ > modify. > It'd be great if there was a spec writeup for discussion - or is this a pre-spec seeds of thoughts? I think Jacob's suggestion of OIDs is not at all unreasonable, and avoids the ambiguities you raise and allows them to be addressed by policy in the Forum. > > It's easy to define a URI mapping for an existing account identifier. > > For instance, if customers have a numeric id 123456, the CA can specify > that > > the corresponding account-uri is https://ca.example.net/accounts/123456. > > There's no requirement that account-uris are fetchable. > > I get that, but a URI is longer and more complicated. Quirin's research > shows that a significant fraction of CAA users CANNOT SPELL THEIR CA'S > NAME. I shudder to think how they will manage to mangle a URI ... > I also agree with Jacob's suggestion here, and prefer a single, canonical representation. --001a1144452e2645c10560a36229 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Dec 18, 2017 at 3:10 PM, Tim Hollebeek <tim.hollebeek= @digicert.com> wrote:

> > readable text labels, like Validation=3DPhone?
>
> My issue with validation=3Dphone is that it is not precise enough; the= re's
one
> version of validation by phone defined in the BRs today, but what if t= hat
> changes significantly? One could solve this by defining a versioned validation
> method, e.g. validation=3Dphone-01, with an IANA registry to register = new
ones
> as requirements change.

The lack of precision bothered me a bit too when I was proposing it,=
especially since some people have discussed breaking up some of the
larger catch-all ones.=C2=A0 I like the version number, but I think we have= to be

a bit careful.=C2=A0 Is the version just a minimum version?=C2=A0 If I have= CAA set to

validation=3Dphone-01, do I have to update my CAA record every time the
BR validation methods are changed?=C2=A0 How big of a change requires revvi= ng
the version number of the validation method?

Should the BR version number be used instead?=C2=A0 E.g. validation=3Dphone= -1.5.4?
This might make more sense as the BR version number does get bumped on
every validation rev (and non-validation rev ...).

> However, there does seem to be some interest in embedding information<= br> > about validation methods in certificates. It would be nice if there wa= s a
> correspondence between the namespace used in CAA and the one used in > certificates.

That would be nice.=C2=A0 Maybe an IANA registry for validation meth= ods might
make sense, but I'm unfamiliar with how easy/difficult that is to set u= p/
modify.

It'd be great if there was = a spec writeup for discussion - or is this a pre-spec seeds of thoughts?

I think Jacob's suggestion of OIDs is not at all= unreasonable, and avoids the ambiguities you raise and allows them to be a= ddressed by policy in the Forum.

=C2=A0

> It's easy to define a URI mapping for an existing account identifi= er.
> For instance, if customers have a numeric id 123456, the CA can specif= y
that
> the corresponding account-uri is https://ca.example.net/<= wbr>accounts/123456.
> There's no requirement that account-uris are fetchable.

I get that, but a URI is longer and more complicated.=C2=A0 Quirin&#= 39;s research
shows that a significant fraction of CAA users CANNOT SPELL THEIR CA'S<= br> NAME.=C2=A0 I shudder to think how they will manage to mangle a URI ...
=

I also agree with Jacob's suggestion h= ere, and prefer a single, canonical representation.=C2=A0

--001a1144452e2645c10560a36229-- From nobody Mon Dec 18 12:45:52 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9D0126CD8 for ; Mon, 18 Dec 2017 12:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0-_Y7LLGvjq for ; Mon, 18 Dec 2017 12:45:48 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585BF1200FC for ; Mon, 18 Dec 2017 12:45:48 -0800 (PST) Received: from [216.82.251.38] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-13.bemta-12.messagelabs.com id 7B/43-24474-BF8283A5; Mon, 18 Dec 2017 20:45:47 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupml+JIrShJLcpLzFFi42K5obCFX/e3hkW UwdYtrBYzr/xks5h0fy6jxbxryQ7MHu8+PWf1WLLkJ5NH8+7dLAHMUayZeUn5FQmsGYc+/WMt +N7CWDH1/AKWBsa9VV2MnBwsAu+ZJH5sqOti5OIQEpjCJPHg6QwmkISQwBFGif9zWUBsNgEDi Wt7j4PFRQTUJB5OP8MKYjMLeEv8v9cEViMsICvx8M5uZogaOYkFB7+yQthuEj0/djBCLFOV+L f1KDuIzSsQIzFv4TkmiMVLmCQ29h0HS3AKBEpM3vMAzGYUEJP4fmoNE8QycYlbT+aD2RICIhI PL55mg7BFJV4+/scKYStJ3F77gxHClpW4NL+bEWSBhMAhdok5u+9AJfQktk58C2X7Smxbe5oF omgZo8SN76+BEhxAjpbExF+BEEfESMz9fAhqWbbEnofnoWwriY6Jx1kheg8zS3T8aGeBSMhIP D7SDTV0GpvEhvOfWSBhmiIxZRXEJGEBKYm7VzoZJzBqzkLy3SygHmaB+YwSvd37WWeBw0lQ4u TMJywQRVESC2ZuYIewtSSmrn0FFdeWWLbwNfMsoMOZBTQljl1WQhUGsa0lZvw6yAZhK0pM6X4 INcZU4vXRj4wLGLlXMaoXpxaVpRbpmuolFWWmZ5TkJmbm6BoaGunlphYXJ6an5iQmFesl5+du YgQmw3oGBsYdjMv++RxilORgUhLlnaVsESXEl5SfUpmRWJwRX1Sak1p8iFGGg0NJgnedOlBOs Cg1PbUiLTMHmJZh0hIcPEoivM/VgNK8xQWJucWZ6RCpU4z2HHP23vrDxLHh5l0guQ9MPpv5uo FZiCUvPy9VSpy3BWSqAEhbRmke3FBYHrnEKCslzMvIwMAgxFOQWpSbWYIq/4pRnINRSZh3Ocg Unsy8Erjdr4DOYgI6a2qEOchZJYkIKakGxsiQgC9Cqw2FzJOSHrcaTf62K5cjnPWlyD3OtSYC scExwsU8kXzRnseTXzvmbwq5rqjjWqygmWjlNCHnjLH+4fxmZYb75ae8z0oYCrvocrIcO3kpR erf8vl6VvmyT54XHAtK8zp+TY1x1+8Vc0ozyi6HFfzZyd/wb0PK7udc7ht/x9R5LYxQYinOSD TUYi4qTgQA1qq1hR4EAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-6.tower-163.messagelabs.com!1513629946!169685907!1 X-Originating-IP: [216.32.180.15] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 122225 invoked from network); 18 Dec 2017 20:45:46 -0000 Received: from mail-sn1nam02lp0015.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) (216.32.180.15) by server-6.tower-163.messagelabs.com with AES256-SHA256 encrypted SMTP; 18 Dec 2017 20:45:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rh1GqczHFsgic5cbwFtQwl4MpT7b5ZFLs3C+YXyOHlU=; b=JkiQq4Rwy5Cl1Yxb/LJjDsXFbmcXKneJrM0Z2zcNv93/AyZLfL6ay3aroDKFYFmxl+QtkKzH1Sm8V7KMdjrB4Y6h4hHlwP17VEkaDgrpaKQ2dujJ1rex+p2ru2QNdsOE71nLD2QgplpGT+C/wG3kAm2A8wd+rTl1CenVBYINce8= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1290.namprd14.prod.outlook.com (10.173.132.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Mon, 18 Dec 2017 20:45:45 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0323.018; Mon, 18 Dec 2017 20:45:45 +0000 From: Tim Hollebeek To: Ryan Sleevi CC: Jacob Hoffman-Andrews , "spasm@ietf.org" Thread-Topic: [lamps] CAA tags Thread-Index: AdN4J3TZ60fppeKgRNaOHREkYP39nwADzsgAAAD5epAAAYUKgAAAB/wg Date: Mon, 18 Dec 2017 20:45:45 +0000 Message-ID: References: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1290; 6:9Nta9C/iaa+2E/lbOlKhu52wGm9vWt+LWyhrEkMDeLnK4/TwPRnlgNSVoIUR/f0IdGt6VPie9ziXhYD67Q/OOiSMbZWA6efm0Oqo9myDD/H4LjFizHg6dYxDjnIgE0/+teorsaKDMwKby30tcVwVxDvmCm6IW5PGH7f+hKivPD0MTC6Hzeb+e/D4mWtrSzCVj5t+q3MpehZG6VnuKQc2Ah2xHxa4edMnTxcWydOr+rKF85B2VEVdXgy4zMEJ761qckP2faBKnTP4hBs61u+PXsMEeOq+LzbI3+DEEPZlOuozEwdiK1koiEmJl/s1p7XeUsLFZyWZ2IYzT/gZULHeWM4gXdZFJPGiyUjqbek+g4k=; 5:Vdwnr1yTzcvI5WwAJFj2sGNIpuYMk0uFandMm/WVqen+acpRxaPAQGlaO/f208xpBzTX2kW78H7rzwiwFkuGZVPJI0hHEpUEuE3l6GRjNqTztHtpax3W1TZTQcohaF+iyW+QRdjBg/JlOAYdiKWdWoDVU4Fc+cfvUtH9g+JN0EM=; 24:dogrzIaltGwA55ps6IVCZ/AZZkCbKa2oYTCrr/fMs4Fv67UiRzs1AWkhNnOXxFUP8AGDMxc1aZG0giGsKN5WPFpOtX+5VcFql/P/vMt+PbQ=; 7:CXiiy6Ug2PPxo/PteHgbEvuvsZAMxw9lmC4MSx4iwsl29cst/MRMGSxN3v6J7qGShZ7HutE3p5MDWWdp58lZ8/1wGuwWEpNs+p5kWOeDpnHP+hbdmo4TLky8AD0N+XjYBO9IT/I3E8oqTOf5FoUvdcyCAYszrYEk7XFh73Sfb/RFJimfw2N7aiD9ahK8+5lKkcUTrbIq9ahO3J5PjSZYq45fkjZ5OmJEwjVhob+60JxizNj28DMq26fIAGsxyRwL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8ef6eb37-dc38-426e-42bf-08d546584fd0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307)(49563074); SRVR:DM5PR14MB1290; x-ms-traffictypediagnostic: DM5PR14MB1290: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231023)(10201501046)(93006095)(93001095)(6041248)(20161123558100)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6043046)(6072148)(201708071742011); SRVR:DM5PR14MB1290; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1290; x-forefront-prvs: 0525BB0ADF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(376002)(366004)(45074003)(199004)(189003)(24454002)(55016002)(14454004)(59450400001)(6306002)(68736007)(3660700001)(93886005)(105586002)(106356001)(6506007)(6436002)(236005)(478600001)(14971765001)(99286004)(966005)(54896002)(54906003)(606006)(53546011)(229853002)(7696005)(9686003)(76176011)(77096006)(316002)(8676002)(3280700002)(97736004)(6916009)(6246003)(25786009)(2950100002)(8936002)(53936002)(5660300001)(4326008)(3846002)(790700001)(6116002)(102836003)(7736002)(2906002)(66066001)(74316002)(99936001)(86362001)(2900100001)(33656002)(81156014)(81166006)(19400905002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1290; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0598_01D37806.7CC29460" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ef6eb37-dc38-426e-42bf-08d546584fd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 20:45:45.1814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1290 Archived-At: Subject: Re: [lamps] CAA tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:45:51 -0000 ------=_NextPart_000_0598_01D37806.7CC29460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0599_01D37806.7CC29460" ------=_NextPart_001_0599_01D37806.7CC29460 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Pre-spec for discussion. It=E2=80=99s current status is =E2=80=9CI sat = down for an hour, reviewed meeting minutes and read some stuff, and = circulated some notes=E2=80=9D. =20 -Tim =20 From: Ryan Sleevi [mailto:ryan-ietf@sleevi.com]=20 Sent: Monday, December 18, 2017 1:42 PM To: Tim Hollebeek Cc: Jacob Hoffman-Andrews ; spasm@ietf.org Subject: Re: [lamps] CAA tags =20 =20 =20 On Mon, Dec 18, 2017 at 3:10 PM, Tim Hollebeek = > wrote: > > readable text labels, like Validation=3DPhone? > > My issue with validation=3Dphone is that it is not precise enough; = there's one > version of validation by phone defined in the BRs today, but what if = that > changes significantly? One could solve this by defining a versioned validation > method, e.g. validation=3Dphone-01, with an IANA registry to register = new ones > as requirements change. The lack of precision bothered me a bit too when I was proposing it, especially since some people have discussed breaking up some of the larger catch-all ones. I like the version number, but I think we have = to be a bit careful. Is the version just a minimum version? If I have CAA = set to validation=3Dphone-01, do I have to update my CAA record every time the BR validation methods are changed? How big of a change requires revving the version number of the validation method? Should the BR version number be used instead? E.g. = validation=3Dphone-1.5.4? This might make more sense as the BR version number does get bumped on every validation rev (and non-validation rev ...). > However, there does seem to be some interest in embedding information > about validation methods in certificates. It would be nice if there = was a > correspondence between the namespace used in CAA and the one used in > certificates. That would be nice. Maybe an IANA registry for validation methods might make sense, but I'm unfamiliar with how easy/difficult that is to set = up/ modify. =20 It'd be great if there was a spec writeup for discussion - or is this a = pre-spec seeds of thoughts? =20 I think Jacob's suggestion of OIDs is not at all unreasonable, and = avoids the ambiguities you raise and allows them to be addressed by = policy in the Forum. =20 > It's easy to define a URI mapping for an existing account identifier. > For instance, if customers have a numeric id 123456, the CA can = specify that > the corresponding account-uri is = https://ca.example.net/accounts/123456. > There's no requirement that account-uris are fetchable. I get that, but a URI is longer and more complicated. Quirin's research shows that a significant fraction of CAA users CANNOT SPELL THEIR CA'S NAME. I shudder to think how they will manage to mangle a URI ... =20 I also agree with Jacob's suggestion here, and prefer a single, = canonical representation.=20 ------=_NextPart_001_0599_01D37806.7CC29460 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Pre-spec = for discussion.=C2=A0 It=E2=80=99s current status is =E2=80=9CI sat down = for an hour, reviewed meeting minutes and read some stuff, and = circulated some notes=E2=80=9D.

-Tim

From: Ryan = Sleevi [mailto:ryan-ietf@sleevi.com]
Sent: Monday, December = 18, 2017 1:42 PM
To: Tim Hollebeek = <tim.hollebeek@digicert.com>
Cc: Jacob Hoffman-Andrews = <jsha@eff.org>; spasm@ietf.org
Subject: Re: [lamps] CAA = tags

On Mon, = Dec 18, 2017 at 3:10 PM, Tim Hollebeek <tim.hollebeek@digicert.com> = wrote:

> > readable text labels, like = Validation=3DPhone?
>
> My issue with validation=3Dphone is = that it is not precise enough; there's
one
> version of = validation by phone defined in the BRs today, but what if that
> = changes significantly? One could solve this by defining a = versioned
validation
> method, e.g. validation=3Dphone-01, with = an IANA registry to register new
ones
> as requirements = change.

The lack of precision bothered me a bit too when I was = proposing it,
especially since some people have discussed breaking up = some of the
larger catch-all ones. I like the version number, = but I think we have to be

a bit careful. Is the version = just a minimum version? If I have CAA set = to

validation=3Dphone-01, do I have to update my CAA record every = time the
BR validation methods are changed? How big of a change = requires revving
the version number of the validation = method?

Should the BR version number be used = instead? E.g. validation=3Dphone-1.5.4?
This might make more = sense as the BR version number does get bumped on
every validation = rev (and non-validation rev ...).

> However, there does seem = to be some interest in embedding information
> about validation = methods in certificates. It would be nice if there was a
> = correspondence between the namespace used in CAA and the one used = in
> certificates.

That would be nice. Maybe an IANA = registry for validation methods might
make sense, but I'm unfamiliar = with how easy/difficult that is to set = up/
modify.

It'd be great if there was a spec writeup for = discussion - or is this a pre-spec seeds of = thoughts?

I = think Jacob's suggestion of OIDs is not at all unreasonable, and avoids = the ambiguities you raise and allows them to be addressed by policy in = the Forum.

> It's = easy to define a URI mapping for an existing account identifier.
> = For instance, if customers have a numeric id 123456, the CA can = specify
that
> the corresponding account-uri is https://ca.example.net/accounts/123456.
> = There's no requirement that account-uris are fetchable.

I get = that, but a URI is longer and more complicated. Quirin's = research
shows that a significant fraction of CAA users CANNOT SPELL = THEIR CA'S
NAME. I shudder to think how they will manage to = mangle a URI ...

I = also agree with Jacob's suggestion here, and prefer a single, canonical = representation.

<= /body> ------=_NextPart_001_0599_01D37806.7CC29460-- ------=_NextPart_000_0598_01D37806.7CC29460 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMjE4MjA0NTM4WjAvBgkqhkiG9w0BCQQxIgQghEFMAto+qAgK5Vtq+/hp6bm06ozV B+62N02ahj/GRbUwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHGZbeoEIVX+FGmoiI3aoacQ7ibz//HIH0LPVvVbnpwQ75iXo7hP8W32FISTVOKf6XLFqki6 8NqUNKh48Wje/kQNH+gUknTKul0armm6JwAVxUqgS6MmnRD75OTfWzSYdDKaF1BBQbZoqafn1MIH jYL0fZLIBlJuGi3mGqU9co5qaDyHaLT5yCQiy7XyNU1OM24t/Snm0UURT/7i4n9ruePtdjXH5pRc kmwPRTPo+S2hzNdPKYvF7Nb+BlI87trVRzpvtsv0sJX9geOCPAzXkXHOgBQLs4Adm9bTcIdKsZpM fptzdBpLJRGeL0w2kWkI3qkaPnmVx7y5qInsUnWHfJoAAAAAAAA= ------=_NextPart_000_0598_01D37806.7CC29460-- From nobody Mon Dec 18 14:02:13 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100A512AF83 for ; Mon, 18 Dec 2017 14:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BTxnsft_uAy for ; Mon, 18 Dec 2017 14:02:08 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADAF124B0A for ; Mon, 18 Dec 2017 14:02:08 -0800 (PST) Received: (qmail 18039 invoked by uid 1004); 18 Dec 2017 22:02:06 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 18 Dec 2017 22:02:06 +0000 Received: from [192.168.0.72] ([178.255.87.226]) by maileu.comodo.net (IceWarp 11.4.6.0 DEB8 x64) with ASMTP (SSL) id 201712182202069492 for ; Mon, 18 Dec 2017 22:02:06 +0000 To: spasm@ietf.org References: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org>

From: Rob Stradling Message-ID: <7531d7e2-2bdd-559a-2e40-286a3fe4a4f2@comodo.com> Date: Mon, 18 Dec 2017 22:02:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] CAA tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 22:02:11 -0000 On 18/12/17 20:42, Ryan Sleevi wrote: > I think Jacob's suggestion of OIDs is not at all unreasonable, and > avoids the ambiguities you raise and allows them to be addressed by > policy in the Forum. We had policy OIDs in early versions of the I-D [1] that later became RFC6844, but we had to strip this out in favour of domain names when the document was adopted by PKIX. WG consensus and all that. I'm not sure what that decision might mean for any other proposals to use OIDs with CAA. [1] https://www.ietf.org/archive/id/draft-hallambaker-donotissue-04.txt -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Dec 18 22:24:01 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00EA1205F0 for ; Mon, 18 Dec 2017 22:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pVE8qoMNwQE for ; Mon, 18 Dec 2017 22:23:59 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77341241FC for ; Mon, 18 Dec 2017 22:23:58 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id p31so9133239ota.4 for ; Mon, 18 Dec 2017 22:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Z1C4UuHiEftLyJG3SvumKmgIB+Oq5XPP0IXRvx1tdRM=; b=JIDAYlL9mdBKUSVZT/gCOWvsi35SrVxGwJVGfRqAwdRcFxH2evcpPEWtLXHZPcrEh4 6y/mkVbJB6PAcrqjGA0R2/iDNuSjQnP9DjKCZdeWLW4CIh1e0GyhXQaCYr3SEw0gFzCu jwIZwbPz/byLJ/svUFsi3n6p0BCaVDCWTnktmGmywrQ/mhN/m5SjzbJMf52rEfYAMGi7 539ov52PnDPDEKH0kDq6c5qFrEAWujZ0plAmSsRWTj8c/qGX52U3ni54gi/2QlsqAaIR v1nHz72ZbuVVAroB2AaAY9qIvmGWvd3e+JlTU88ayo8/vHao19M5zwElScNpiL3DCr8l tFUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Z1C4UuHiEftLyJG3SvumKmgIB+Oq5XPP0IXRvx1tdRM=; b=ZbGmxPUV9qOFxHywKgHDpLsxYTN7FncTAibQDsMm94sagj1DNjQmvlK42QSgsei6oA hbn9olxy6IzpGwe7acP4skSFeGPBl9yRrZMZxZMsTkZsZ2YdgKHkVCqj2DydYslAu0bT U0YtBlhkQxttz9p8JRIVKf6LZ2uQV0b8b5SNBeXQdfJIZWBlod1h+SfiG7NSBpVLvBk3 gtqPUKpcgeEx6D9V4cWQ+kDp/McUbxMdTaeG1YabSuE23iksNcQHjiRBFM4+ySObc3GT 0Qhutclmfj1VAKHM10CRmvji71+qzK484HhDh9IhpFjXG8GZSQbsQoR39AOULo/Vnpyk VoJA== X-Gm-Message-State: AKGB3mJf5jApeXeFw0GxijqOtom531PwlZWUD0KSe5jZf4K90eQypgKT 5wgupgOfu+J7BrYqc3BRw7y1ak2KkQZB+0t41Io= X-Google-Smtp-Source: ACJfBotcyXnXOx1h+09ezvVzDfQgqMf2bdRt+MgTwDPGYNbiFS1V2/9xAbEAOo/QSJh6Qnr72xMd2Tehtn6HA0wj67k= X-Received: by 10.157.26.36 with SMTP id a33mr1768387ote.149.1513664638139; Mon, 18 Dec 2017 22:23:58 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.49.87 with HTTP; Mon, 18 Dec 2017 22:23:57 -0800 (PST) In-Reply-To: <7531d7e2-2bdd-559a-2e40-286a3fe4a4f2@comodo.com> References: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org>

<7531d7e2-2bdd-559a-2e40-286a3fe4a4f2@comodo.com> From: Phillip Hallam-Baker Date: Tue, 19 Dec 2017 01:23:57 -0500 X-Google-Sender-Auth: COOl-ehJyAkVagckQbvL5yjZrwE Message-ID: To: Rob Stradling Cc: SPASM Content-Type: multipart/alternative; boundary="001a1141fb7c10c11c0560ab8305" Archived-At: Subject: Re: [lamps] CAA tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 06:24:00 -0000 --001a1141fb7c10c11c0560ab8305 Content-Type: text/plain; charset="UTF-8" We did indeed start with OIDs. But the reason I agreed to Domain Names was that the suggestion (I seem to remember it was Paul Hoffman) was obviously the right one. Most of the things people want to do with tags can be done with domain names. More importantly, it can be done outside the IETF. If you want 'any EV' issuer, get the CABForum to approve ev.cabforum.com for the purpose. Restricting to specific validation methods is interesting and might be a justified use for the criticality flag. The other point to ponder is how a server that needs a cert discovers where the cert issuing service is. The idea was that if the CAA record specifies chosenca.com, a server would then be able to use that information to work out how to get a cert and automate the whole process. Remember that at the time, there was this idea that DNS records should not make use of prefixes and should not make use of additional parsing beyond DNS record markers. At this point, I think we can safely ignore both notions as broken and if I was to do it again would suggest it just be a TXT type record. But we can't that's water under the bridge now, sorry. On Mon, Dec 18, 2017 at 5:02 PM, Rob Stradling wrote: > On 18/12/17 20:42, Ryan Sleevi wrote: > > >> I think Jacob's suggestion of OIDs is not at all unreasonable, and avoids >> the ambiguities you raise and allows them to be addressed by policy in the >> Forum. >> > > We had policy OIDs in early versions of the I-D [1] that later became > RFC6844, but we had to strip this out in favour of domain names when the > document was adopted by PKIX. WG consensus and all that. > > I'm not sure what that decision might mean for any other proposals to use > OIDs with CAA. > > > [1] https://www.ietf.org/archive/id/draft-hallambaker-donotissue-04.txt > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a1141fb7c10c11c0560ab8305 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

We = did indeed start with OIDs. But the reason I agreed to Domain Names was tha= t the suggestion (I seem to remember it was Paul Hoffman) was obviously the= right one.=C2=A0

Most of= the things people want to do with tags can be done with domain names. More= importantly, it can be done outside the IETF. If you want 'any EV'= issuer, get the CABForum to approve ev.= cabforum.com for the purpose.

Restricting to specific validation methods is interesting and mi= ght be a justified use for the criticality flag.=C2=A0

The other point to ponder is how a server tha= t needs a cert discovers where the cert issuing service is. The idea was th= at if the CAA record specifies chosenca.com= , a server would then be able to use that information to work out how t= o get a cert and automate the whole process.

Remember that at the time, there was this idea that DNS records = should not make use of prefixes and should not make use of additional parsi= ng beyond DNS record markers. At this point, I think we can safely ignore b= oth notions as broken and if I was to do it again would suggest it just be = a TXT type record. But we can't that's water under the bridge now, = sorry.

On Mon, Dec 18, 2017 at 5:02 PM, Rob St= radling <rob.stradling@comodo.com> wrote:
On 18/12/17 20:42, Ryan Sleevi wrote:
<snip>

I think Jacob's suggestion of OIDs is not at all unreasonable, and avoi= ds the ambiguities you raise and allows them to be addressed by policy in t= he Forum.

We had policy OIDs in early versions of the I-D [1] that later became RFC68= 44, but we had to strip this out in favour of domain names when the documen= t was adopted by PKIX.=C2=A0 WG consensus and all that.

I'm not sure what that decision might mean for any other proposals to u= se OIDs with CAA.

[1] https://www.ietf.org/archive/= id/draft-hallambaker-donotissue-04.txt=

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--001a1141fb7c10c11c0560ab8305-- From nobody Tue Dec 19 04:13:37 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4B012426E for ; Tue, 19 Dec 2017 04:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDbsYat1XVWI for ; Tue, 19 Dec 2017 04:13:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A8F12422F for ; Tue, 19 Dec 2017 04:13:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 55757BE2F; Tue, 19 Dec 2017 12:13:32 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOfabxGveZ28; Tue, 19 Dec 2017 12:13:32 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07DB8BE77; Tue, 19 Dec 2017 12:13:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513685604; bh=U7xiuzckn47l5uGLk0O+PiF8/VzQ+AdwsMT9pyKhD8k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GObFit53gEpxo6P+ffm+wsBvBDWcHouTGfnUuczmj/GWHQ4YaMt58nlPNI93iE4NK Z0L3ryk7sMVDCKWMDtlpB/9OOXYdtucYuyXV4D/7UxRl4LaRMWYcesokv+9nmXSFtx uSVoE1iOhZvmgz/W6U+eRimJMgDH5cMx9gHYWf+w= To: Tim Hollebeek Cc: "spasm@ietf.org" References: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org>

From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 19 Dec 2017 12:13:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BtEoc1ebOBDuBTbGnJIEnUmDffT646xdS" Archived-At: Subject: Re: [lamps] CAA tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 12:13:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BtEoc1ebOBDuBTbGnJIEnUmDffT646xdS Content-Type: multipart/mixed; boundary="jHi0cebXX8EARRFbLsGOP2SooTon2krCO"; protected-headers="v1" From: Stephen Farrell To: Tim Hollebeek Cc: "spasm@ietf.org" Message-ID: Subject: Re: [lamps] CAA tags References: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org>

In-Reply-To: --jHi0cebXX8EARRFbLsGOP2SooTon2krCO Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, I've not been following this closely but since you said: On 18/12/17 20:45, Tim Hollebeek wrote: > Pre-spec for discussion. It=E2=80=99s current status is =E2=80=9CI sat= down for an > hour, reviewed meeting minutes and read some stuff, and circulated > some notes=E2=80=9D. I guess it may be ok to throw in a requirement to keep an aspect of the status quo: I'd like to ensure it remains possible for a whole bunch of DNS domains to use the same CAA RR value and for that to continue to make sense. I've no problem if optional things can be added that are domain-specific so long as I don't have to create custom CAA values for every domain. My reason for wanting that is that I deal with sets of domains who can all currently sensibly use the same CAA value and that's easy to handle. If I had to go changing the value for each, esp if that had to be re-done regularly, or even worse, sporadically, that'd be a PITA. Apologies for the interruption if this is already taken as a given, but I wasn't sure based on the recent mails about phone numbers etc. Thanks, S. --jHi0cebXX8EARRFbLsGOP2SooTon2krCO-- --BtEoc1ebOBDuBTbGnJIEnUmDffT646xdS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaOQJiAAoJEC88hzaAX42imPwH/30H4Lu3xxKDQFar8M9EjtJZ wsJJpXn2ezU8uLrfm2NOwEmiOCYaA2Me0XILua1Vf9f9aPvDLTj8wS/Y4fRGELhk JGqXX5Dw4Vw26Wn63NOjYHdFxOOMySqzgVv6hFd7Un0KytLij+jS6XCrWFvWAEOm +Au6jj6j+ABijeq0R+smIuGIWCHzYHhPVaP+0TAIXqKzx2ujbhzzTD/Yg92jPRu7 Fa20Zb9g8cxmYewqW7Caz+S6DRKJtCy2jfiil7NdB801iH8uQg72ymL6IvqzGRTY NGwQMlLszBpYCvydQuauYPDaWjRF3ZSr2eimMdCkz7KLIbJIOR1TeZASt8ttIXA= =hz5b -----END PGP SIGNATURE----- --BtEoc1ebOBDuBTbGnJIEnUmDffT646xdS-- From nobody Tue Dec 19 06:26:01 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7891270A7 for ; Tue, 19 Dec 2017 06:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.918, TRACKER_ID=1.306, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjCgNLqoHiHH for ; Tue, 19 Dec 2017 06:25:57 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D27126CD8 for ; Tue, 19 Dec 2017 06:25:57 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 74576C009F58 for ; Tue, 19 Dec 2017 06:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=KAKHOZgoDndl9r8zM3QFmaWbC9M=; b= kH2Rhvze5/U7Xc+qxRpV1y7JkTXZMxWh5wBQJ1xKT+qRFTrNA7an+eauo43gv4w+ /LbqRcSEy6qniaMH6T6kUMJxiRpyjgtzvSajcew2JG3pY7UW4uoFoi2GZt0Tj5dt eZad5/5f37ppjO25yEfsZg8Ik/b5Zm5KYpq/yLDwuYA= Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 4B225C009F53 for ; Tue, 19 Dec 2017 06:25:56 -0800 (PST) Received: by mail-io0-f172.google.com with SMTP id x129so13775584iod.13 for ; Tue, 19 Dec 2017 06:25:56 -0800 (PST) X-Gm-Message-State: AKGB3mK80kUMO4E8FFA0JnVnIl7ma0nwLzJe0jUrlCcZ7/d8ZoGdgwUz HAzmjB9bdulf8PgCCxXralar+WDth21G6E8mX+o= X-Google-Smtp-Source: ACJfBovdw0Ha1NXQIxCTMuAtsj2CeNvoLz6M7gNV5hbA3JE2ApG0d0O13EK6ZRm7ytAIUT8d0sNvXZ5IhuvSMFlIEb4= X-Received: by 10.107.46.169 with SMTP id u41mr4115727iou.303.1513693555308; Tue, 19 Dec 2017 06:25:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.78.70 with HTTP; Tue, 19 Dec 2017 06:25:54 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Tue, 19 Dec 2017 09:25:54 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Tim Hollebeek Cc: Jacob Hoffman-Andrews , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="001a11c146eea9c1120560b23e05" Archived-At: Subject: Re: [lamps] CAA tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 14:25:59 -0000 --001a11c146eea9c1120560b23e05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tim, >From a design consideration, if/as you look to write this up, it would be useful to understand why you pursued the route of issuer-specific parameters, rather than as new properties. That is, why is the set of policy not CAA issue 0 "example.com" CAA issue 0 "example.net" CAA validation 128 "type=3DEV method=3D1,2,3,4" Which limits issuance to example.com and example.net, iff the validation method of domain control employs methods 1, 2, 3, or 4, and the resultant process uses the EV process? [*] This obviously precludes the notion of 'account' - but I think that's illustrative of the point; something like 'account' is inherently CA-specific, while the validation methods or types are CA agnostic. The benefit of this, for a Subscriber, is they might omit the publication of an issue tag, thus not constraining per-CA, but still scoping the validation methods. Understandably, this design could also be accounted for with the CABForum declaring some pseudo-domain to express such CA-agnostic properties, such as: CAA issue 0 "example.com; type=3DDV,EV method=3D1,2,3,4" # If exampl= e.com is issuing, support for both DV and EV, using methods 1-4 CAA issue 0 "validation.cabforum.org; type=3DEV method=3D1,2,3" # Otherwise= , support for EV only using methods 1-3 There are both strengths and weaknesses of both proposals, so it'd be great to see a discussion about the problem statement and desired workflows. [*] I provide these for simplicity of typing - but I think any restriction of both 'type' and 'method' needs to be versioned, as the CABF documents do change On Mon, Dec 18, 2017 at 12:41 PM, Tim Hollebeek wrote: > Here is my tags proposal, in case others want to comment on it on this > list. > > > > Note that it has been privately pointed out to me that one possible > solution to the criticality problem and the scaling problem is to use > top-level tags that are independent of the issue records: > > > > Something like: > > > > CAA 0 issue =E2=80=9Ca.example.com=E2=80=9D > > CAA 0 issue =E2=80=9Cb.example.com=E2=80=9D > > CAA 128 validation =E2=80=9CPhone=E2=80=9D > > > > -Tim > > > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------------------- > Introduction and Motivation > > > > In addition to being able to specify which CA or CAs are allowed to issue > certificates for a given domain, RFC 6844 allows additional parameters, > such as the account number, that the CA can consume for a variety of uses= . > RFC 6844 defines the format, but otherwise leaves the kinds of properties > and their meanings up to the issuer. > > While this is appropriate for a technical standard, standardizing the > names and meanings of CAA properties across the CA industry has the > following benefits: > > 1. Reduce user confusion when the same or similar property is used by > different CAs with different names and semantics > 2. Make it simpler to migrate from one CA to another while preserving > the CAA configuration > 3. Simplifying configuration and expression of CAA policies that allow > issuance from multiple CAs > 4. Allow CAA record creation tools to support creating CAA records > that contain properties that have been standardized > > History > > > > CAA property tags have been discussed at several CA/B Forum meetings, mos= t > recently at the October meeting in Taipei. Four were suggested: Acceptab= le > validation methods, an account identifier, certificate types (DV/OV/EV), > and ability to specify a brand. > > > Method of Adoption > > > > Since these CAA properties are just a voluntary industry standard that an= y > CA could implement, they don=E2=80=99t necessarily have to exist in a sta= ndards > document. However, it seems like it would be helpful if the names and > semantics were agreed upon by the industry as a whole, so it is probably > best to include them in the Baseline Requirements as an optional feature > CAs MAY implement. > > On the other hand, it might be desirable to reserve the names, and requir= e > that if these particular property names are used, the semantics MUST be t= he > semantics specified in the Baseline Requirements. > > > Brands > > > > I=E2=80=99m starting with this one because I=E2=80=99m going to argue it = isn=E2=80=99t necessary. > CAs can and do have multiple names that they accept in CAA records. It i= s > hard to imagine a brand existing without the associated domain and websit= e > also existing. I=E2=80=99d suggest that CAs that maintain multiple brand= s simply > use a different domain name for each brand, e.g. > > certs.example.com CAA 0 issue =E2=80=9Cmegaca.com=E2=80=9D > > catlover.example.com CAA 0 issue =E2=80=9Ccertsforcats.com=E2=80= =9D # > certsforcats is a brand owned by MegaCA. > > CAAs can also publicize examples of CAA records that allow for issuance b= y > all of their brands. > Acceptable Validation Methods > > > > A list of acceptable validation methods can be specified using the > =E2=80=9Cvalidation=E2=80=9D tag. > > There are two challenges here, that have been discussed elsewhere in > relation to keeping records of which validation method was used for a > particular certificate. The first is that validation methods can change > over time. This seems to be less of a concern for issuance than it is fo= r > historical validations, as a CAA record can and should be interpreted as > always requiring the version of the method that is enforced by the BRs at > issuance time. However, this can cause the exact meaning of a CAA record > to change over time as the BRs evolve. I don=E2=80=99t think this is a b= ig > problem, but wanted to note it. > > The second issue is that it is possible that the numbering of the BR > validation methods could potentially change over time. For that reason, = I > think it might be reasonable to standardize on a label for each validatio= n > method, that can be used in addition to the section number: > > *BR Section (BR v. 1.5.4)* > > *Short Section* > > *Validation method label* > > 3.2.2.4.1 > > 1 > > DomainContact > > 3.2.2.4.2 > > 2 > > EmailOrSimilar > > 3.2.2.4.3 > > 3 > > Phone > > 3.2.2.4.4 > > 4 > > ConstructedEmail > > 3.2.2.4.5 > > 5 > > DomainAuthorizationDocument > > 3.2.2.4.6 > > 6 > > WebsiteChange > > 3.2.2.4.7 > > 7 > > DNSChange > > 3.2.2.4.8 > > 8 > > IPAddressLookup > > 3.2.2.4.9 > > 9 > > TestCertificate > > 3.2.2.4.10 > > 10 > > RandomValueInCertificate > > > > Examples: > > CAA 0 issue =E2=80=9Cca.example.net; validation=3D3=E2=80=9D = # Call me > about all certificates > > CAA 0 issue =E2=80=9Cca.example.net; validation=3DPhone=E2=80=9D = # Same as > previous example > > CAA 0 issue =E2=80=9Cca.example.net; validation=3D1,2,3,4,7,8,9,10=E2=80= =9D # I don=E2=80=99t > like DADs and website changes > > CAA 0 issue =E2=80=9Cca.example.net; validation=3D!5,6=E2=80=9D = # Same as > previous example. Worth the trouble? > Account Identifier > > > > This one is relatively straightforward, as the identifier is going to be > CA-specific anyway. Use the =E2=80=9Caccount=E2=80=9D keyword: > > CAA 0 issue =E2=80=9Cca.example.net; account=3D8675309=E2=80=9D > > The format and values of the account specifier is up to the individual CA= . > Acceptable Certificate Types > > > > This one also seems to be relatively straightforward. I=E2=80=99ve chose= n to make > the categories disjoint, so if you=E2=80=99re ok with more than one type,= you have > to specify more than one. Use the =E2=80=9Ctype=E2=80=9D keyword. > > CAA 0 issue =E2=80=9Cca.example.net; type=3DEV=E2=80=9D = # EV only > > CAA 0 issue =E2=80=9Cca.example.net; type=3DDV=E2=80=9D = # DV only > > CAA 0 issue =E2=80=9Cca.example.net; type=3DOV,EV=E2=80=9D = # No DV > Lack of Property Tag Value Criticality > > > > Supporting the various properties is optional. Unlike the CAA =E2=80=9Ci= ssue=E2=80=9D > property, these properties do not have to be ubiquitously supported to ha= ve > value, because Domain holders can restrict their issue records to only > include CAs that have publicly stated that they support the desired > property tags. > > For example, if CAs A, B, and C support the =E2=80=9Ctype=3DEV=E2=80=9D t= ag, then the > following will prevent non-EV issuance: > > CAA issue 0 =E2=80=9CA.com; type=3DEV=E2=80=9D > > CAA issue 0 =E2=80=9CB.com; type=3DEV=E2=80=9D > > CAA issue 0 =E2=80=9CC.com; type=3DEV=E2=80=9D > > Unfortunately, this does scale poorly with a large number of CAs. > > The problem is that RFC 6844 supports =E2=80=9CCritical=E2=80=9D for prop= erty tags (like > =E2=80=9Cissue=E2=80=9D), but there is no way to mark a parameter tag is = =E2=80=9CCritical=E2=80=9D. I > intend to bring this up with the IETF WG. > > Any easy solution is to use reserved bit #1 for property tag criticality: > CAA issue 64 =E2=80=9CA.com; type=3DEV=E2=80=9D # type=3DEV ta= g must be respected; > # > cannot issue if you don=E2=80=99t understand or enforce it. > > > Multiple Tags > > > > Just for completeness, these individual features can also be used togethe= r: > > CAA issue 0 =E2=80=9Cca.example.com; type=3DEV validation=3DPhone account= =3D8675309=E2=80=9D > > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --001a11c146eea9c1120560b23e05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Tim,

From a design consideration, if/as= you look to write this up, it would be useful to understand why you pursue= d the route of issuer-specific parameters, rather than as new properties.

That is, why is the set of policy not

CAA issue 0 "example.com"

CAA issue 0 "example.= net"

CAA validation 128 "type=3DEV method=3D1,2,3,4= "

Which limits issuance to example.com and example.net= , iff the validation method of domain control employs methods 1, 2, 3, = or 4, and the resultant process uses the EV process? [*]

This obviously precludes the notion of 'account' - but I thi= nk that's illustrative of the point; something like 'account' i= s inherently CA-specific, while the validation methods or types are CA agno= stic.=C2=A0

The benefit of this, for a Subscriber,= is they might omit the publication of an issue tag, thus not constraining = per-CA, but still scoping the validation methods.

= Understandably, this design could also be accounted for with the CABForum d= eclaring some pseudo-domain to express such CA-agnostic properties, such as= :

CAA issue 0 "example.com; type=3DDV,EV method=3D1,2,3,4"=C2=A0 =C2=A0 =C2=A0 = =C2=A0 # If example.com is issuing, supp= ort for both DV and EV, using methods 1-4

CAA issue 0 "validation.cabforum.org; type=3DE= V method=3D1,2,3" # Otherwise, support for EV only using methods 1-3

There are both strengths and weaknesses of both pro= posals, so it'd be great to see a discussion about the problem statemen= t and desired workflows.

[*] I provide these for s= implicity of typing - but I think any restriction of both 'type' an= d 'method' needs to be versioned, as the CABF documents do change

On Mon,= Dec 18, 2017 at 12:41 PM, Tim Hollebeek <tim.hollebeek@digicert.= com> wrote:

Here is my tags = proposal, in case others want to comment on it on this list.<= /p>
=C2=A0
Note that it has been privately= pointed out to me that one possible solution to the criticality problem an= d the scaling problem is to use top-level tags that are independent of the = issue records:
=C2=A0
So= mething like:
=C2=A0
CAA 0 issue =E2=80=9Ca.example.com=E2=80=9D=
CAA 0 issue =E2=80=9Cb.example.com=E2=80=9D=
CAA 128 validation =E2=80= =9CPhone=E2=80=9D
=C2=A0
-Tim
=C2=A0
-----------= -----------------------------------------------------------------= -----------------------------------------------------------------= ----------
Introduction and Motivation<= /u>
=C2=A0
In addition to being able to specify which CA or CAs are allowed to issu= e certificates for a given domain, RFC 6844 allows additional parameters, s= uch as the account number, that the CA can consume for a variety of uses.= =C2=A0 RFC 6844 defines the format, but otherwise leaves the kinds of prope= rties and their meanings up to the issuer.
While this is appropriate for a technical standard, standardizing t= he names and meanings of CAA properties across the CA industry has the foll= owing benefits:
Reduce user confusion when the same or similar propert= y is used by different CAs with different names and semantics=
Make it simpler to migrate from one CA to another while pr= eserving the CAA configuration
Simplifying co= nfiguration and expression of CAA policies that allow issuance from multipl= e CAs
Allow CAA record creation tools to suppor= t creating CAA records that contain properties that have been standardized<= u>
History
=C2=A0
CAA property tags have been= discussed at several CA/B Forum meetings, most recently at the October mee= ting in Taipei.=C2=A0 Four were suggested: Acceptable validation methods, a= n account identifier, certificate types (DV/OV/EV), and ability to specify = a brand.
=C2=A0
Method of Adoption
=C2=A0=
Since these CAA properties are just a vol= untary industry standard that any CA could implement, they don=E2=80=99t ne= cessarily have to exist in a standards document.=C2=A0 However, it seems li= ke it would be helpful if the names and semantics were agreed upon by the i= ndustry as a whole, so it is probably best to include them in the Baseline = Requirements as an optional feature CAs MAY implement.
On the other hand, it might be desirable to reserve the= names, and require that if these particular property names are used, the s= emantics MUST be the semantics specified in the Baseline Requirements.
=C2=A0
Brands
=C2=A0
I=E2=80=99m starting with this one because I=E2=80=99m going to ar= gue it isn=E2=80=99t necessary.=C2=A0 CAs can and do have multiple names th= at they accept in CAA records.=C2=A0 It is hard to imagine a brand existing= without the associated domain and website also existing.=C2=A0 I=E2=80=99d= suggest that CAs that maintain multiple brands simply use a different doma= in name for each brand, e.g.
certs.example.com=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 CAA 0 issue =E2=80=9Cmegaca.com=E2=80=9D
catlover.example.com=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CAA 0 issue =E2=80=9C certsforcats.com=E2= =80=9D=C2=A0=C2=A0=C2=A0 # certsforcats is a brand owned by MegaCA.<= u>
CAAs can also publicize examples of CAA re= cords that allow for issuance by all of their brands.
= Acceptable Validation Methods
<= /u>=C2=A0
A list of acceptable validation = methods can be specified using the =E2=80=9Cvalidation=E2=80=9D tag.=
There are two challenges here, that have = been discussed elsewhere in relation to keeping records of which validation= method was used for a particular certificate.=C2=A0 The first is that vali= dation methods can change over time.=C2=A0 This seems to be less of a conce= rn for issuance than it is for historical validations, as a CAA record can = and should be interpreted as always requiring the version of the method tha= t is enforced by the BRs at issuance time.=C2=A0 However, this can cause th= e exact meaning of a CAA record to change over time as the BRs evolve.=C2= =A0 I don=E2=80=99t think this is a big problem, but wanted to note it.<= /u>
The second issue is that it is possibl= e that the numbering of the BR validation methods could potentially change = over time.=C2=A0 For that reason, I think it might be reasonable to standar= dize on a label for each validation method, that can be used in addition to= the section number:

BR Section = (BR v. 1.5.4)	Short Section	Validation method = label
3.2.2.4.1	1	DomainContact
3.2.2.4.2	2	EmailOrSimilar
3.2.2.4.3	3	Phone
3.2.2.4.4	4	ConstructedEmail
3.2.2.4.5	5	DomainAuthorizationDocument
3.2.2.4.6	6	WebsiteChange
3.2.2.4.7	7	DNSChange
3.2.2.4.8	8	IPAddressLookup
3.2.2.4.9	9	TestCertificate
3.2.2.4.10	10	RandomValueInCertificate

3.2.2.4.3

<= td width=3D"196" valign=3D"top" style=3D"width:147.1pt;border:solid windowt= ext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">

3.2.2.4.4

<= tr>

BR Section (BR v. 1.5.4)<= /b>	Short Section	Valida= tion method label
3.2.2.4.1	1	DomainContact
3.2.2.4.2=	2	EmailOrSimilar
= 3	Phone
4	ConstructedEmail =
3.2.2.4.5	5	DomainAuthorization= Document
3.2.2.4.6	6	WebsiteChange
3.2.2.4.7<= /u>	7	DNSChange
3.2.2.4.8	8	IPAddressLookup
3.2.= 2.4.9	9	TestCertificate
3.2.2.4.10	10	RandomValueInCertificate=

=C2=A0

Examples:

CAA 0 issue =E2=80=9Cca.example.net; validation=3D3=E2=80=9D=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 # Call me about all certificates

CAA 0 issue =E2=80=9Cca.example.net; validation=3DPhone=E2=80=9D= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # = Same as previous example

CAA 0 issu= e =E2=80=9Cca.example.n= et; validation=3D1,2,3,4,7,8,9,10=E2=80=9D=C2=A0=C2=A0 # I don=E2=80=99= t like DADs and website changes

CAA= 0 issue =E2=80=9Cca.ex= ample.net; validation=3D!5,6=E2=80=9D=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Same= as previous example.=C2=A0 Worth the trouble?

Account= Identifier

=C2=A0

This one is relatively straightforward, as the ide= ntifier is going to be CA-specific anyway.=C2=A0 Use the =E2=80=9Caccount= =E2=80=9D keyword:

CAA 0 issue =E2= =80=9Cca.example.net; account=3D8675309=E2=80=9D

The f= ormat and values of the account specifier is up to the individual CA.

Acceptable Certificate Types

=C2=A0

This one also see= ms to be relatively straightforward.=C2=A0 I=E2=80=99ve chosen to make the = categories disjoint, so if you=E2=80=99re ok with more than one type, you h= ave to specify more than one.=C2=A0 Use the =E2=80=9Ctype=E2=80=9D keyword.=

CAA 0 issue =E2=80=9Cca.example.net; type=3DEV=E2=80= =9D=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 # EV only

CAA 0 issue =E2=80=9C= ca.example.net; typ= e=3DDV=E2=80=9D=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # DV only

CAA 0 issu= e =E2=80=9Cca.example.n= et; type=3DOV,EV=E2=80=9D=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # No DV<= /u>

Lack of Property Tag Value Criticality

=C2=A0

Suppo= rting the various properties is optional.=C2=A0 Unlike the CAA =E2=80=9Ciss= ue=E2=80=9D property, these properties do not have to be ubiquitously suppo= rted to have value, because Domain holders can restrict their issue records= to only include CAs that have publicly stated that they support the desire= d property tags.

For example, if CA= s A, B, and C support the =E2=80=9Ctype=3DEV=E2=80=9D tag, then the followi= ng will prevent non-EV issuance:

CA= A issue 0 =E2=80=9CA.com; type=3DEV=E2=80=9D

CAA issue 0 =E2=80=9CB.com; type=3DEV=E2=80=9D

<= p class=3D"MsoNormal">CAA issue 0 =E2=80=9CC.com; type=3DEV=E2=80=9D=

Unfortunately, this does scale poorly wit= h a large number of CAs.

The proble= m is that RFC 6844 supports =E2=80=9CCritical=E2=80=9D for property tags (l= ike =E2=80=9Cissue=E2=80=9D), but there is no way to mark a parameter tag i= s =E2=80=9CCritical=E2=80=9D.=C2=A0 I intend to bring this up with the IETF= WG.

Any easy solution is to use re= served bit #1 for property tag criticality:

CAA issue 64 =E2=80=9CA.com; type=3DEV=E2=80=9D=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # type=3DEV= tag must be respected;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # cannot = issue if you don=E2=80=99t understand or enforce it.
=C2=A0

Multiple Tags<= u>

=C2=A0

Just for completeness, these individual features can also be used tog= ether:

CAA issue 0 =E2=80=9Cca.example.com; type=3DEV = validation=3DPhone account=3D8675309=E2=80=9D

=C2=A0

Introduction and = Motivation

History

Method of = Adoption

Brands

Acceptable Validation = Methods

Account = Identifier

Acceptable Certificate = Types

Lack of Property Tag Value = Criticality

CAA issue 64 “A.com; = type=3DEV” &nb= sp; # type=3DEV tag must be = respected; = ; = &= nbsp; &n= bsp; &nb= sp; # cannot issue if = you don’t understand or enforce it.

Multiple = Tags

Introduction and Motivation<= /u>

History

Brands

= Acceptable Validation Methods

Account= Identifier

Acceptable Certificate Types

Lack of Property Tag Value Criticality

Multiple Tags<= u>

CAA issue 64 “A.com; = type=3DEV” &nb= sp; # type=3DEV tag must be = respected;
= ; = &= nbsp; &n= bsp; &nb= sp; # cannot issue if = you don’t understand or enforce it.