[cabf_validation] F2F minutes

[Jeremy Rowley]

1.	Backlog ballots

a.	Non-latin qualified notaries
b.	SRVNames
c.	ASN.1 for JOI

2.	Ballot 190 Experiences 

a.	Everyone generally agreed that the documentation/revision storage
was fairly difficult. Most are storing the information as a date that
correlates to a BR version
b.	Jeremy said there's a lot of inconsistency in the language that we
need to fix
c.	Tim said the random value means two different things - sometimes it
means a nonce and sometimes it is a secret. Redefining the term will clarify
the confusion
d.	The language sometimes refers to an unknown actor.  The room agreed
generally that the CA should be the actor in all cases. This requires
clarification
e.	Jeremy said there's confusion about whether items can be used
cross-method.  Tim said this is clarified once we fix the nonce/secret
confusion
f.	Document/information reuse is confusing. 
g.	The scope of the domain approval is also confusing.  Sometimes the
document says FQDN, other times it says authorization domain. Once it says
base domain
h.	The document is also unclear on the scope of the approval. How does
a subscriber know they are approving sub domains. Gerv asked if we should
require scope approval during the verification. Jeremy thought this was a
good idea. 
i.	Resuability is unclear. Each method should state what can be reused
and what needs to be redone.  Each method should also state what how long
specific actions are good for.

3.	Ballot 190 Issues

a.	Jeremy showed the issues list
b.	The validation WG will go through the list on their call

4.	IP Address validation

a.	The last proposal was circulated on March 24th
b.	The ballot eliminates the "any other method"
c.	Jeremy recirculated the proposal for discussion on the mailing list

5.	CAA Experiences 

a.	The biggest question was about how systems should behave if DNS
doesn't answer. This was partly discussed on the mailing list.  There are
two options. First, if there is no record, assume the record is permissive
for the CA. Second, if there is no record keep working the chain. The first
is the correct interpretation but CAs are permitted to be more restrictive.
b.	Others felt CAA was not mature enough for adoption.  The RFC needed
more clarification before we tried to implement.
c.	Peter brought up that DNSSEC implementations lacked quality.  CAs
are required to fail open if DNSSEC is not present, but fail close if DNSSEC
is present.
d.	There are issues with split horizon
e.	Some failures are caused by CNAME loops
f.	People have seen issues with malformed records. CAA needs better
implementation tools as these are generally caused by manual input
processes.
g.	Lesson learned - these new ideas need a more phased-in approach.
h.	There was a lengthy discussion about CAA and the audit, especially
as it pertains to the errata.  What happens now that the browser and audit
requirements differ? Ultimately, this became a non-issue as neither WebTrust
nor ETSI would updated before the errata requirement went into effect.
i.	The validation WG said they would write a normalization document.
j.	CAA for IP Addresses is an IETF issue, not something to discuss in
the WG
k.	CAA flags. Four were suggested: Validation methods, account
identifier, certificate types, and brands

                                                               i.
There's a question whether the WG will cover these or a new CAA WG will
create them

6.	Root and Intermediate Requirements

a.	We discussed modifying 7.1.4.3.1(b). Right now it specifies that the
Sub CA must be listed in the  O field.  There's a question whether vanity
issuing CAs are permitted. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20171019/5e6002a4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4984 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20171019/5e6002a4/attachment.p7s>