Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Sun, May 27, 2018 at 3:00 PM, Richard Barnes  wrote:

> Updated PR:
>
> Responses to comments Github: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/710ef835446231ef954b0f6e448718eef04b63fa
> Responses to this email: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/3dd2a10ee55c13ff87772463374a7c0ab4205d5f
>
> Trimming points on which we agree...
>
> On Fri, May 25, 2018 at 12:09 PM Eric Rescorla  wrote:
>
>> > > IMPORTANT
>> > > S 6.2.
>> > > > algorithm in its "alg" field
>> > > >
>> > > >  o  The JWS Payload MUST NOT be detached
>> > > >  o  The JWS Protected Header MUST include the following fields:
>> > > >
>> > > > *  "alg" (Algorithm)
>> > >
>> > > Do you want to specify a set of acceptable signature algorithms here?
>> >
>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>> > required algorithms, and we don't want to conflict.  I guess you
>> > could specify some MUST NOTs pretty safely, but given that they're
>> > already forbidden by CABF, it seems kind of duplicative.
>>
>> This is about the signatures that ACME accepts, not the signatures
>> in certs. Does CABF have a position on what signature algorithms
>> that ACME uses?
>>
>
> Good point.  As Ryan pointed out, this is not something on which there is
> currently CABF guidance.
>
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
> If they're positive "MUST support" requirements, then we would need to come
> back and revise this document in the event of an algorithm break (though
> admittedly, that would be pretty far down on the TODO list).  And looking
> at the current list of JWS algorithms, I don't see any I would MUST NOT,
> except possibly the ones based on SHA-1
>

Hmm... Common practice in security protocols is to specify MTI algorithms.
Why is this different?




> >
> Perhaps just a forward reference.
>
> "Further down" here just means "the next paragraph".  Over that distance,
> I don't think a forward reference is really helpful :)
>

OK.



>
>>
>> > > S 7.1.2.
>> > > > initiated deactivation.
>> > > >
>> > > >  contact (optional, array of string):  An array of URLs that the
>> > > > server can use to contact the client for issues related to
>> this
>> > > > account.  For example, the server may wish to notify the
>> client
>> > > > about server-initiated revocation or certificate expiration.
>> > >
>> > > How am I supposed to know the semantics of these strings? And if they
>> > > are non-mailto URLs, what am I supposed to do with them.
>> >
>> > To first order, the semantic is defined by the scheme of the URL --
>> > "mailto" says "email me", "sip" or "tel" says "give me a call", etc.
>> > We have the "unsupportedContact" error type if the server doesn't
>> > know how to leverage a given scheme.
>>
>>
>> > Of course there are URL schemes that don't make sense as a contact
>> > point (e.g., "data:"), but trying to enumerate those seems quixotic.
>> > Better for the CA to check and reject with the error code we have
>> > provided.
>>
>> Well, http would also be hard to know what to do.
>>
>> My semantic question, however was: are these all equivalent and
>> undifferentiated?
>>
>
> I'm not sure I totally understand the question here, but I think the
> answer is "yes".  Either the server has code to handle a given contact URL
> scheme or it doesn't, in which case unsupportedContact.
>
>

This doesn't seem entirely clear:
1. What do I send to the HTTP URI, if anything? What method do I use?
2. If there is >1 URI, are they all semantically equivalent.



>> > > S 7.4.
>> > > >
>> > > >  The order object returned by the server represents a promise
>> that if
>> > > >  the client fulfills the server's requirements before the
>> "expires"
>> > > >  time, then the server will be willing to finalize the order
>> upon
>> > > >  request and issue the requested certificate.  In the order
>> object,
>> > > >  any authorization referenced in the "authorizations" array
>> whose
>> > >
>> > > What if the CSR contains extensions which are not mentioned here? For
>> > > instance, say I request a given EKU that the CA doesn't like? Or the
>> > > DelegatedUsage extension from https://tools.ietf.org/html/draft-ietf-
>> > > tls-subcerts-00#section-4.1
>> >
>> > [[ DISCUSS - 1e9937c ]]
>> >
>> > This is an unforutunate consequence of not providing the CSR up
>> > front.  It seems like the right outcome here is for the finalization
>> > request to fail.  It's unclear to me whether the order should also
>> > be invalidated.
>>
>> > I think my proposal would be to fail the finalization, but leave the
>> > order open, and the client can re-try with a CSR that the server
>> > might like better.
>>
>> It seems like the implication of this is that it's not possible to
>> demand additional validation procedures at 

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

Forwarding to the list, per Richard.

On Sun, May 27, 2018 at 3:00 PM, Richard Barnes  wrote:

> Updated PR:
>
> Responses to comments Github: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/710ef835446231ef954b0f6e448718eef04b63fa
> Responses to this email: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/3dd2a10ee55c13ff87772463374a7c0ab4205d5f
>
> Trimming points on which we agree...
>
> On Fri, May 25, 2018 at 12:09 PM Eric Rescorla  wrote:
>
>> > > IMPORTANT
>> > > S 6.2.
>> > > > algorithm in its "alg" field
>> > > >
>> > > >  o  The JWS Payload MUST NOT be detached
>> > > >  o  The JWS Protected Header MUST include the following fields:
>> > > >
>> > > > *  "alg" (Algorithm)
>> > >
>> > > Do you want to specify a set of acceptable signature algorithms here?
>> >
>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>> > required algorithms, and we don't want to conflict.  I guess you
>> > could specify some MUST NOTs pretty safely, but given that they're
>> > already forbidden by CABF, it seems kind of duplicative.
>>
>> This is about the signatures that ACME accepts, not the signatures
>> in certs. Does CABF have a position on what signature algorithms
>> that ACME uses?
>>
>
> Good point.  As Ryan pointed out, this is not something on which there is
> currently CABF guidance.
>
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
> If they're positive "MUST support" requirements, then we would need to come
> back and revise this document in the event of an algorithm break (though
> admittedly, that would be pretty far down on the TODO list).  And looking
> at the current list of JWS algorithms, I don't see any I would MUST NOT,
> except possibly the ones based on SHA-1.
>
>
>
>>
>>
>> > > S 6.3.
>> > > >  As noted in Section 6.2 above, all ACME request objects carry
>> a "url"
>> > > >  header parameter in their protected header.  This header
>> parameter
>> > > >  encodes the URL to which the client is directing the request.
>> On
>> > > >  receiving such an object in an HTTP request, the server MUST
>> compare
>> > > >  the "url" header parameter to the request URL.  If the two do
>> not
>> > > >  match, then the server MUST reject the request as unauthorized.
>> > >
>> > > I think you probably need to provide a clear definition of how you
>> > > "compare" them. Is it memcmp? Something else?
>> >
>> > This is specified further down:
>> >
>> > """
>> > The server SHOULD perform the corresponding string equality check,
>> > configuring each resource with the URL string provided to clients
>> > and having the resource check that requests have the same string in
>> > their “url” header parameter.
>> > """
>>
>> Perhaps just a forward reference.
>>
>
> "Further down" here just means "the next paragraph".  Over that distance,
> I don't think a forward reference is really helpful :)
>
>
>
>>
>> > > S 7.1.2.
>> > > > initiated deactivation.
>> > > >
>> > > >  contact (optional, array of string):  An array of URLs that the
>> > > > server can use to contact the client for issues related to
>> this
>> > > > account.  For example, the server may wish to notify the
>> client
>> > > > about server-initiated revocation or certificate expiration.
>> > >
>> > > How am I supposed to know the semantics of these strings? And if they
>> > > are non-mailto URLs, what am I supposed to do with them.
>> >
>> > To first order, the semantic is defined by the scheme of the URL --
>> > "mailto" says "email me", "sip" or "tel" says "give me a call", etc.
>> > We have the "unsupportedContact" error type if the server doesn't
>> > know how to leverage a given scheme.
>>
>>
>> > Of course there are URL schemes that don't make sense as a contact
>> > point (e.g., "data:"), but trying to enumerate those seems quixotic.
>> > Better for the CA to check and reject with the error code we have
>> > provided.
>>
>> Well, http would also be hard to know what to do.
>>
>> My semantic question, however was: are these all equivalent and
>> undifferentiated?
>>
>
> I'm not sure I totally understand the question here, but I think the
> answer is "yes".  Either the server has code to handle a given contact URL
> scheme or it doesn't, in which case unsupportedContact.
>
>
>
>> > > S 7.4.
>> > > >
>> > > >  The order object returned by the server represents a promise
>> that if
>> > > >  the client fulfills the server's requirements before the
>> "expires"
>> > > >  time, then the server will be willing to finalize the order
>> upon
>> > > >  request and issue the requested certificate.  In the order
>> object,
>> > > >  any authorization referenced in the "authorizations" array
>> whose
>> > >
>> > > What if the CSR contains extensions which are not mentioned here? For
>> > > 

Re: [Acme] I-D Action: draft-ietf-acme-caa-04.txt

[Hugo Landau]

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Automated Certificate Management Environment 
> WG of the IETF.
> 
> Title   : CAA Record Extensions for Account URI and ACME 
> Method Binding
> Author  : Hugo Landau
>   Filename: draft-ietf-acme-caa-04.txt
>   Pages   : 9
>   Date: 2018-05-27
> 
> Abstract:
>The CAA DNS record allows a domain to communicate issuance policy to
>CAs, but only allows a domain to define policy with CA-level
>granularity.  However, the CAA specification also provides facilities
>for extension to admit more granular, CA-specific policy.  This
>specification defines two such parameters, one allowing specific
>accounts of a CA to be identified by URI and one allowing specific
>methods of domain control validation as defined by the ACME protocol
>to be required.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-caa/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-caa-04
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-caa-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-caa-04

This is a reissue of -03. There are no changes other than the date.

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

[Acme] I-D Action: draft-ietf-acme-caa-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : CAA Record Extensions for Account URI and ACME Method 
Binding
Author  : Hugo Landau
Filename: draft-ietf-acme-caa-04.txt
Pages   : 9
Date: 2018-05-27

Abstract:
   The CAA DNS record allows a domain to communicate issuance policy to
   CAs, but only allows a domain to define policy with CA-level
   granularity.  However, the CAA specification also provides facilities
   for extension to admit more granular, CA-specific policy.  This
   specification defines two such parameters, one allowing specific
   accounts of a CA to be identified by URI and one allowing specific
   methods of domain control validation as defined by the ACME protocol
   to be required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-caa/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-caa-04
https://datatracker.ietf.org/doc/html/draft-ietf-acme-caa-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-caa-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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