Re: [lamps] CAA tags

[Tim Hollebeek <[e-mail]>]

Pre-spec for discussion.  It’s current status is “I sat down for an hour, reviewed meeting minutes and read some stuff, and circulated some notes”.

 

-Tim

 

From: Ryan Sleevi [mailto:[e-mail]] 
Sent: Monday, December 18, 2017 1:42 PM
To: Tim Hollebeek <[e-mail]>
Cc: Jacob Hoffman-Andrews <[e-mail]>; [e-mail]
Subject: Re: [lamps] CAA tags

 

 

 

On Mon, Dec 18, 2017 at 3:10 PM, Tim Hollebeek <[e-mail] <mailto:[e-mail]> > 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.