Re: [lamps] CAA tags

[Tim Hollebeek <[e-mail]>]

> > 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