Re: [Acme] Before entering WGLC ...

2017-06-20 Thread Salz, Rich
> This might be easier to read, though is actually slightly longer:
>   Where a CAA property has an "account-uri" parameter, a CA MUST NOT
>   consider that property to authorize issuance in the context of a given
>   certificate issuance request unless the CA recognises the URI
>   specified as identifying the account making that request.

I like this.  Martin and Russ, your views?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


Re: [Acme] Before entering WGLC ...

2017-06-20 Thread Hugo Landau
> A CA MAY proceed with issuance if a CAA record is present whose value matches 
> the account-uri parameter of the account making the request.
> If no CAA records have such a match, then the CA MUST NOT proceed with 
> issuance.
This neglects to include the other criteria for validation of a CAA
record, however; the wording here suggests this is the only aspect of a
CAA record that needs to be validated. If you want to describe a
sufficient condition, rather than a necessary one, it stands to reason
you'd have to copy and paste large amounts of language from the CAA
specification into the specification.


Currently we have
  A CA MUST only consider a property with an "account-uri" parameter to
  authorize issuance where the URI specified is an URI that the CA
  recognises as identifying the account making a certificate issuance
  request.

We could also negate it, which might actually be better - the above is
slightly more susceptible to be confused for a statement of a sufficient
condition:
  A CA MUST NOT consider a property with an "account-uri" parameter to
  authorize issuance unless the URI specified is an URI that the CA
  recognises as identifying the account making a certificate issuance
  request.

This might be easier to read, though is actually slightly longer:
  Where a CAA property has an "account-uri" parameter, a CA MUST NOT
  consider that property to authorize issuance in the context of a given
  certificate issuance request unless the CA recognises the URI
  specified as identifying the account making that request.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


Re: [Acme] Before entering WGLC ...

2017-06-19 Thread Salz, Rich
How about this:

A CA MAY proceed with issuance if a CAA record is present whose value matches 
the account-uri parameter of the account making the request.
If no CAA records have such a match, then the CA MUST NOT proceed with issuance.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


Re: [Acme] Before entering WGLC ...

2017-06-19 Thread Hugo Landau
> Like Russ, I find the statement very difficult to read.  Would
> inverting it be better?
> 
> > A CA MUST NOT issue authorize issuance if a CAA record is present unless 
> > the "account-uri" parameter identifies the account making a certificate 
> > issuance request.
See previous reply. Issuance is not determined by the presence of "a"
CAA record; there may be multiple and issuance is authorized if any are
considered to match the request. Establishing that a specific CAA record
is not matched is not a sufficient condition for refusing issuance,
because another adjacent CAA record might authorise it. I think any
attempt to describe this criterion in terms of specific situational MUST
NOTs with regard to a single CAA record is futile.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


Re: [Acme] Before entering WGLC ...

2017-06-18 Thread Martin Thomson
Like Russ, I find the statement very difficult to read.  Would
inverting it be better?

> A CA MUST NOT issue authorize issuance if a CAA record is present unless the 
> "account-uri" parameter identifies the account making a certificate issuance 
> request.


On 19 June 2017 at 00:16, Salz, Rich  wrote:
> Thank you.  For me, it addresses the issue.  Russ, are you ok?
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


Re: [Acme] Before entering WGLC ...

2017-06-18 Thread Salz, Rich
Thank you.  For me, it addresses the issue.  Russ, are you ok?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


Re: [Acme] Before entering WGLC ...

2017-06-17 Thread Salz, Rich
> >    . . .  A CA MUST only consider a property with an "account-uri"
> >    parameter to authorize issuance where the URI specified is an URI
> >    that the CA recognises as identifying the account making a
> >    certificate issuance request.
> >
> > > This is not a [crisp] MUST statement.  I think it is trying to say two 
> > > things
> when the "account-uri" is present:
> >
> > > (1)  the CA MUST NOT issue a certificate containing the domain name that
> contains the CAA Resource Record if it does not recognize the account
> referenced by the URI.
> >
> > > (2)  the CA MUST use the account referenced by the URI in the
> authorization process for a certificate request for the domain containing the
> CAA Resource Record.
> >
> > > If this is correct, please separate these two requirements.  If it is not
> correct, please explain the text.
> >
> > Can you post an update next week?  If not, would it help to add another
> author to do so?  I would like to move this forward to the IESG soon.  Please
> respond by early next week.
> 
> I don't understand this issue. The wording is clear.

It's understandable, yes.   Does Russ's proposal have the same meaning?   I'm 
not sure.  That means, I think that the original wording could stand a bit of 
clarification.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


Re: [Acme] Before entering WGLC ...

2017-06-17 Thread Hugo Landau
> Hugo, the CAA document is in WGLC.  Russ raised the following issue on some 
> text in section 2:
> 
>    . . .  A CA MUST only consider a property with an "account-uri"
>    parameter to authorize issuance where the URI specified is an URI
>    that the CA recognises as identifying the account making a
>    certificate issuance request.
> 
> > This is not a [crisp] MUST statement.  I think it is trying to say two 
> > things when the "account-uri" is present: 
> 
> > (1)  the CA MUST NOT issue a certificate containing the domain name that 
> > contains the CAA Resource Record if it does not recognize the account 
> > referenced by the URI.
> 
> > (2)  the CA MUST use the account referenced by the URI in the authorization 
> > process for a certificate request for the domain containing the CAA 
> > Resource Record.
> 
> > If this is correct, please separate these two requirements.  If it is not 
> > correct, please explain the text.
> 
> Can you post an update next week?  If not, would it help to add another 
> author to do so?  I would like to move this forward to the IESG soon.  Please 
> respond by early next week.

I don't understand this issue. The wording is clear.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


[Acme] Before entering WGLC ...

2017-06-16 Thread Salz, Rich
Hugo, the CAA document is in WGLC.  Russ raised the following issue on some 
text in section 2:

   . . .  A CA MUST only consider a property with an "account-uri"
   parameter to authorize issuance where the URI specified is an URI
   that the CA recognises as identifying the account making a
   certificate issuance request.

> This is not a [crisp] MUST statement.  I think it is trying to say two things 
> when the "account-uri" is present: 

> (1)  the CA MUST NOT issue a certificate containing the domain name that 
> contains the CAA Resource Record if it does not recognize the account 
> referenced by the URI.

> (2)  the CA MUST use the account referenced by the URI in the authorization 
> process for a certificate request for the domain containing the CAA Resource 
> Record.

> If this is correct, please separate these two requirements.  If it is not 
> correct, please explain the text.

Can you post an update next week?  If not, would it help to add another author 
to do so?  I would like to move this forward to the IESG soon.  Please respond 
by early next week.

Thank you.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme