Re: [cabfpub] [Ext] [Servercert-wg] Voting Begins: SC13 version 5: CAA Contact Property and Associated E-mail Validation Methods

[Paul Hoffman via Public]

> On Dec 20, 2018, at 8:32 AM, Rob Stradling via Servercert-wg 
>  wrote:
> 
> Sectigo votes NO.
> 
> We don't object to the idea behind this ballot, and we don't have any 
> specific objections to the content of this ballot either.  However, the 
> IETF has a process for defining new CAA properties, and this process 
> needs to be followed.
> 
> https://tools.ietf.org/html/rfc6844#section-7.2 says:
>   "Addition of tag identifiers requires a public specification and
>Expert Review as set out in [RFC6195], Section 3.1.1."
> 
> The BRs is a "public specification", certainly.  However, *before* the 
> new CAA property proposed by this ballot can become enshrined as a 
> requirement in the BRs:
>   1. An application for "Expert Review" must be submitted
>   and
>   2. An "approved" response from the designated Expert must be received
> 
> Since IANA has not yet assigned any Expert(s) to the caa-properties 
> registry [1], it's clear that the required "Expert Review" has not yet 
> occurred.
> 
> 
> [1] 
> https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa-properties

It is worthwhile noting the paragraph of RFC 6844 immediately after the one 
quoted above:

   The tag space is designed to be sufficiently large that exhausting
   the possible tag space need not be a concern.  The scope of Expert
   Review SHOULD be limited to the question of whether the specification
   provided is sufficiently clear to permit implementation and to avoid
   unnecessary duplication of functionality.

Even though there is not yet an expert reviewer (which is odd, given that 
they've had almost six years to make that assignment), this text makes it sound 
like the registration in this ballot would very likely be accepted, and if it 
wasn't, an appeal would almost certainly win. 

If this ballot passes, someone from CABForum should send a message to the IESG 
saying "there was no reviewer, we added a property that we think meets the 
requirements, and as soon as you assign an expert reviewer (cough cough) we 
will submit this to the registry".

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Re: List of which CAs use which methods from Section 3.2.2.4?

[Paul Hoffman via Public]

On Jul 12, 2018, at 12:51 PM, Wayne Thayer  wrote:
> Paul- can explain your use case for this information? That might help us 
> determine if the proposal is worth pursuing.

There are communities who use certificates who trust some BR-allowed methods 
more than others. Some of the methods are more prone to BGP rerouting than 
others, for example.

At this point, I don't have any good estimates for them to indicate how many 
CAs use which method, much less how many certificates in common use are likely 
to use particular methods. As Ryan pointed out, transparency here is pretty 
low. That affects users' trust of CAs in general, and it would be grand if I 
could say "here's what the relying parties know about the certificates in use".

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] List of which CAs use which methods from Section 3.2.2.4?

[Paul Hoffman via Public]

Greetings. I am interested in finding out which member CAs use each of the 
methods listed in Section 3.2.2.4 of the BRs. I looked around the CABF web site 
and could not find any such list, but could have missed it. If the CABF doesn't 
keep such a list, does anyone know of an external researcher who has created 
such a list in the past few years?

Note that I'm not asking for each CA to say on this mailing list "we use 
3.2.2.4.1 and 3.2.2.4.6"; that would not be a good use of bandwidth here. I 
just hope that someone has already collected that data.

A related request would be for the CAs that allow multiple methods to report 
somewhere what percentage of their certificates from the last year were from 
each method. I really don't expect that to exist as a whole, but maybe CAs are 
reporting this on their own sites.

If no one is collecting this information, maybe the CABF could start?

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] [EXTERNAL] Associate Member status and meeting participation by related entities

[Paul Hoffman via Public]

On May 29, 2018, at 11:35 AM, Kirk Hall via Public  wrote:
> ICANN has tended to be represented only by Francisco Arias, who is an 
> employee, I think.  I don’t have experience with Tscheme on this issue.

Francisco is indeed an employee of ICANN. :-) So am I, but I don't participate 
in the meetings yet. If I need to in the future, I'm happy to do so under 
whatever rules y'all want.

--Paul Hoffman

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] For Discussion: S/MIME Working Group Charter

[Paul Hoffman via Public]

(Unlurking, this time as one of the IETF's S/MIME WG chairs for more than a 
decade)

> On May 24, 2018, at 7:39 AM, Ryan Sleevi via Public  
> wrote:
> 
> ... the basic foundation of how you validate an e-mail address is going to be 
> key. Whether that's by validating the domain holder and allowing them to 
> self-attest to the correctness of every email (much like we allow them to do 
> so with subdomains beneath an ADN) or whether that's validating directly to 
> the email address, at the core, we need to make sure that the rfc822Name 
> within an S/MIME certificate is sufficiently validated.

Although I was never a mail client vendor, I worked extensively with them to 
develop and test S/MIME. What Ryan says here was of great concern to the 
vendors at the time. There was a fair number who said "we want to use the 
subset of the web CAs that we believe know how to validate email addresses 
before they issue certificates" but instead were kinda forced into mostly 
supporting only internally-generated certificates.

> That's why my concrete encouragement was to start with S/MIME BRs as the sole 
> deliverable. Work through the operational and issuance profile, work through 
> the core validation mechanisms, and table discussions that would otherwise 
> detract from that. Once we've got a common and understood baseline, then it 
> can be explored whether there are more rigorous forms that are both possible 
> and useful.

>From the discussions in the IETF's S/MIME WG of 15ish years ago, I suspect 
>that finishing just that one topic will be intensive and interesting enough 
>for the group to then decide if it wants to bite off more. Regardless, 
>finishing it and having the CABForum be able to say "we have a new solid set 
>of BRs for S/MIME certificate issuance" will bring goodwill in the communities 
>that still rely on S/MIME. Those BRs could easily be adapted to other secure 
>email message technologies that might come out in the future. In other words, 
>it would be great if the CABForum could at least start there.

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] BR Authorized Ports, add 8443

[Paul Hoffman via Public]

On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public  wrote:
> 
> Forwarding from Richard Wang:
> 
> The current BRs say:
> 
> Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 
> (smtp), 22 (ssh).
> 
> But many internal networks use the port 8443, broadly used in Apache server, 
> today, one of our customers uses this port and can't change to use another 
> port, I wish you can help to add this port 8443 to be allowed in the BRs, 
> thanks.

It appears that the BRs currently are talking about authorizing *services*, not 
ports. That is, I would not expect to be able to put a HTTP server on port 22 
on my system and have that considered authorized by the BRs.

Any Internet service can be run on any port. Every web, SMTP, and SSH server 
software configuration allows you to run on the standard ports or any port you 
choose.

Two suggestions:

- Clarify the BRs to say "Authorized Services and Ports"

- Add text that says only the authorized ports may be used

If CABF folks want to allow issuance of certificates for services on ports 
other than the standard ports, you will have to decide what it means to 
initially offer a service on one part and then move it to another port. The 
PKIX standard does not allow encoding of port numbers for services in 
certificates.

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Ballot XXX: Update Discussion Period

[Paul Hoffman via Public]

On Dec 8, 2017, at 7:38 AM, Kirk Hall via Public  wrote:
> In the past, we have let ballot authors correct typos - such as "certificaet" 
> to "certificate".  Would that no longer be allowed (meaning, would that type 
> of editing to a ballot require the restart of a new seven day discussion 
> period)?

In the IETF, when similar situations happen, there is often disagreement about 
whether this one little change is editorial or has technical effects. However, 
that disagreement often comes up a few days after the change was made, making 
reverting difficult if other changes have been made subsequently. The draft 
numbering scheme in the IETF looks arcane and nerdy, but it has made it easier 
to see when an editorial change is actually a technical change and cleanly 
revert it. I don't know if that would work in the CABForum.

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] New RFC on CT Domain Label Redaction

[Paul Hoffman via Public]

On Nov 21, 2017, at 7:03 AM, Gervase Markham via Public  
wrote:
> 
> On 03/11/17 23:23, Kirk Hall via Public wrote:
>> This email is to lay out the course we want to follow to complete the
>> technical specs for Redaction in the IETF, and also to address the
>> recourse issues and consider appropriate changes to the Forum’s Baseline
>> Requirements in response.
> 
> In order to try and bring some light to this discussion, I have
> attempted to summarise the arguments for and against CT redaction here:
> https://wiki.mozilla.org/CA/CT_Redaction
> 
> I can only extract data from recently-posted messages and IDs, so the
> document is clearly incomplete. If you have an additional consideration
> to add, or a response to an existing one, or want to improve the text,
> feel free - it's a wiki. If you are unable or unwilling to get a login
> (they do need approving, but it doesn't normally take long) then you can
> send edits to me, although I reserve the right to edit your edits ;-)

Please do consider sharing the link to the file with the LAMPS WG in the IETF. 
It would help their discussion as well.

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Relation to the IETF

[Paul Hoffman via Public]

On Sep 26, 2017, at 9:40 PM, Kirk Hall via Public  wrote:
> Certainly we have the power to do this, and it has nothing to do with IETF or 
> standards setting bodies

Just a small nit here, but the IETF often appreciates hearing from other bodies 
who are implementing IETF standards about how that implementation is going, 
even if the message is "the standard is wrong here and here". Hearing that from 
a group of providers/vendors is more useful than hearing it from just an 
individual. It doesn't have to be an official communication (since the IETF and 
the CABForum don't have liaisons). A message to a related IETF mailing list 
saying "we found this when we implemented, we documented it here, let us know 
if we can be of more help" is very useful to the IETF process.

--Paul Hoffman (not speaking for anyone)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Voting has started on Ballot 21 - CAA Discovery CNAME Errata

[Paul Hoffman via Public]

Related to this tread, a post on the dns-operations mailing list from just now:

https://lists.dns-oarc.net/pipermail/dns-operations/2017-September/016752.html
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] CAA checking: anecdotal reports?

[Paul Hoffman via Public]

Greetings. I'm interested in how CAA is working out for both the names and CA 
communities.

Is someone collecting anecdotal reports of certificate non-issuance due to CAA 
checking? I kind of imagine they fall into at least two buckets: "I really do 
own the name but don't know how that wrong CAA record got there" and "As a CA, 
we have seen X blocked attempts to use us to try to get certs that had CAA 
records from other vendors". I guess I'm also interested in "About X% of our 
renewals are names that have us correctly listed in a CAA record".

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] [EXTERNAL] Ballot 212: Canonicalise formal name of the Baseline Requirements

[Paul Hoffman via Public]

On Aug 21, 2017, at 1:59 PM, Kirk Hall via Public  wrote:
> Gerv, I was asked by my team “what problem is this ballot solving”?  Not in 
> opposition, but just wondering why we need it?

An outside view:

I have had to point people to the BR a few times, and have sometimes gotten 
back "is that their membership rules?" and "are there other sets of 
requirements?". Having a single stable name for your single important document 
would be helpful to those outside CABForum. (It's not just the IETF who has 
naming problems!)

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Ballot 202 - Underscore and Wildcard Characters

[Paul Hoffman via Public]

On Aug 1, 2017, at 11:50 AM, Erwann Abalea  wrote:
> I personally think the new definition is clear and unambiguous; a label is 
> composed of arbitrary octets, and can even be empty (which is the case for 
> the root). But for the new definition to fit our purpose, we may need to also 
> include a mention to the « Global DNS » (a new addition in 7719bis), which 
> clarifies the label lengths, global length, common root, and other things.

Indeed. The DNSOP WG realized that some definitions in RFC 7719 have a hidden 
assumption of "the DNS that we all know but don't really name", but others 
applied to "domain names that are not part of the DNS, such as '.onion'". That 
difference probably applies to the BRs.

> One question for Paul: at Global DNS/Composition of names, it is said that a 
> domain name has a max length of 255 octets in wire format, and the root 
> represents one octet. Does that octet account for the leading dot, or in 
> addition to the leading dot?

Neither. In the *wire* format from RFC 1035, there are no dots. Each label has 
one octet that is a length field with a value between 0 and 63, and then that 
number of octets following.

The *display* format is the one with the dots.

> In other words, should an FQDN expressed in a SAN:dNSName be limited to 254 
> octets, or 253 octets?

253.

Display format (in ASCII notation): www.example.com

Wire format (in hex notation): 0377076578616d706c6503636f6d00

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Ballot 202 - Underscore and Wildcard Characters

[Paul Hoffman via Public]

On Jul 31, 2017, at 11:57 AM, Peter Bowen <p...@amzn.com> wrote:
> 
> 
>> On Jul 31, 2017, at 11:20 AM, Paul Hoffman via Public <public@cabforum.org> 
>> wrote:
>> 
>> To (apologetically) throw a spanner into the works here: RFC 7719 is being 
>> revised, and this very definition is changing to be clearer. The current 
>> draft says:
>> 
>>  Label:  An ordered list of zero or more octets and which makes up a
>> portion of a domain name.  Using graph theory, a label identifies
>> one node in a portion of the graph of all possible domain names.
> Is there a draft of 7719bis or a WG that is covering the revision?

The draft can be found at
   https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
It is a work item of the DNSOP WG
   https://datatracker.ietf.org/wg/dnsop

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Ballot 202 - Underscore and Wildcard Characters

[Paul Hoffman via Public]

On Jul 31, 2017, at 10:45 AM, Rich Smith via Public  wrote:
> 
> Hi Peter,
> Overall, I like your suggestions, but could I ask that in definitions where 
> you refer to outside RFC definitions that you include those outside 
> definitions verbatim so that someone reading the BRs does not have to go 
> scouring through all the various RFCs?  For example:
> Change:
> Domain Label: A “label” as defined in RFC 7719
>  
> To:
> Domain Label: A “Label” as defined in RFC 7719: The identifier of an 
> individual node in the sequence of nodes identified by a fully qualified 
> domain name.
>  
> This will make it much easier to parse the BRs on their own.  Also, I know in 
> general that as a best practice simply pointing to the reference is better so 
> that if the reference definition changes, so would our definitions w/out 
> having to take further action.  However in this situation, I would consider 
> that a bug rather than a feature.  I don’t think we should allow changes to 
> externally referenced definition to automatically change our definitions, at 
> least in this case, without discussion and voting.

To (apologetically) throw a spanner into the works here: RFC 7719 is being 
revised, and this very definition is changing to be clearer. The current draft 
says:

   Label:  An ordered list of zero or more octets and which makes up a
  portion of a domain name.  Using graph theory, a label identifies
  one node in a portion of the graph of all possible domain names.


--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] .well-known and re-directs

[Paul Hoffman via Public]

On Jul 18, 2017, at 8:35 PM, Jeremy Rowley via Public  
wrote:
> 
> We recently encountered a reoccurring scenario while using .well-known to 
> validate a certificate. The customer is trying to validate basedomain.com 
> using http://basedomain.com/.well-known/pki-validation/[page]. However, the 
> server redirects this to 
> https://www.basedomain.com/.well-known.pki-valdiation/[page]  Because 
> basedomain.com cannot be used to verify www.basedomain.com, the validation 
> fails.  Is this the correct result?

No, definitely not. Their server is misconfigured. RFC 5785 says nothing about 
redirects, and many of the registered /.well-known/ prefixes do not redirect.

> Or is a returned random value through a re-direct sufficient to verify the 
> base domain? 

If the BRs allow "we got the correct returned random from an unexpected URI", 
yes. Otherwise, probably not.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Last Call: (Internationalization Updates to RFC 5280) to Proposed Standard

[Paul Hoffman via Public]

Greetings. I didn't see this message about the IETF Last Call on this document 
sent here, but it could certainly be of interest to CABForum members.

Forwarded message:

The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: -
'Internationalization Updates to RFC 5280'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2017-07-25. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   These updates to RFC 5280 provide clarity on the handling of
   Internationalized Domain Names (IDNs) and Internationalized Email
   Addresses in X.509 Certificates.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ballot/

No IPR declarations have been submitted directly on this I-D.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Fixup ballot for CAA

[Paul Hoffman via Public]

On Jul 11, 2017, at 10:42 AM, Ryan Sleevi  wrote:
> Is there a reason not to simply include the errata text as an Appendix
> to the BRs (thus ensuring the necessary IP protections as well), and
> then remove that once/if the CAA document is updated?
> 
> This seems clearer and with one less dependency - namely, on the
> CABForum website.

Ryan's proposed solution seems more stable, for the reason given.

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Updated Ballot 190 v4 dated June 30, 2017

[Paul Hoffman via Public]

On Jun 30, 2017, at 3:47 PM, Kirk Hall  wrote:
> 
> Paul - how does this look?  Thanks for your help.
>  
> Note: Once the FQDN has been validated using this method, the CA MAY also 
> issue Certificates for other FQDNs that have more labels than the validated 
> FQDN and end in the validated FQDN.  This method is suitable for validating 
> Wildcard Domain Names.

Yes, that seems much more explicit.

--Paul Hoffman

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Updated Ballot 190 v3 dated June 30, 2017

[Paul Hoffman via Public]

> On Jun 30, 2017, at 3:04 PM, Kirk Hall via Public  wrote:
>  
> “Note: Once the FQDN has been validated using this method, the CA MAY also 
> issue Certificates for other FQDNs that end in the validated FQDN.  This 
> method is suitable for validating Wildcard Domain Names.”
>  
> We think that is short and simple, and can’t be misconstrued.

It can be misconstrued, and similar wording has been misconstrued in DNS 
software in the past.

For a validated FQDN of "example.com", "accounting-example.com" is an FQDN that 
ends in the validated FQDN. 

If you mean "has more labels than the validated FQDN" (as I suspect that you 
do), it is probably worthwhile to say that directly.

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Fixup ballot for CAA

[Paul Hoffman via Public]

On Jun 13, 2017, at 8:14 AM, Gervase Markham via Public  
wrote:
> 
> On 13/06/17 15:33, Phillip via Public wrote:
>> I do not see a good argument for including the text in the BR and a good
>> reason not to.
> 
> Well, you may not consider it a good argument, but the recommendation of
> ICANN's Principal Technologist is certainly _an_ argument.

This has nothing to do with ICANN, just the IETF. Phill and I each have decades 
of experience with the IETF processes and their evolution.

>> One of the things that we have attempted to maintain is a separation of
>> concerns between CABForum and IETF so that CABForum does not do protocol and
>> IETF does not do policy.
> 
> Quite so. CAB Forum should not try and define what the erratum says.
> This is merely a question of the best way to reference a stable piece of
> text.

Exactly. Phill is saying that he believes that the text in an erratum is 
stable, and I'm saying that I hope it is true but wouldn't trust that. To make 
it clearer, you could put the text in the BR saying "this text matches Erratum 
5029 to RFC 6844 at the time this revision is published".

Note that Erratum 5029 has not yet been accepted by the IETF. It and the other 
two submitted by Phill are still in the "Reported" state, not "Held for 
Document Update". See 

 for the status.

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Ext] Fixup ballot for CAA

[Paul Hoffman via Public]

On Jun 9, 2017, at 9:38 AM, Gervase Markham via Public  
wrote:
> 
> On 06/06/17 09:42, Gervase Markham via Public wrote:
>> So if and when we do think PHB's algorithm tweak is both stably defined
>> and an improvement, then amending the BRs to specifically incorporate
>> the erratum seems like the right fix, because that erratum can not be
>> Verified (which would mean it was automatically incorporated).
> 
> Further to this, I am advised that although errata numbers are supposed
> to be stable for a given version of the text, this is not to be relied
> upon. I therefore suggest that, once the errata text is stable and
> agreed to be correct, we incorporate the text directly into the BRs.

This seems sensible. Although the RFC Editor's errata system is supposed to be 
stable and have long-lived tracking, no one has really tested it, and it seems 
like the CAA requirement might be long-lived. It is thus better to put the diff 
from the RFC directly into the base requirements.

--Paul Hoffman
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public