Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Richard Barnes]

"Always be closing" :)

Or to cite a more ancient source:
"Quidquid facies, respice ad mortem"
"Whatever you do, contemplate death"
-- Seneca

On Thu, Jan 17, 2019 at 4:09 PM Salz, Rich  wrote:

> Richard always wants to close WG’s.  :) His views don’t necessarily
> reflect those of the AD’s or Chairs or the WG itself.  Don’t worry about it
> being more than just one opinion of an involved person. :)
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-star-04

[Diego R. Lopez]

Hi Daniel,

We forked it for obvious reasons, so we could focus on the STAR evolution 
without being concerned about the mainstream Boulder. We’d love to merge it 
back, should the Boulder community be interested.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 17/01/2019, 15:28, "Daniel McCarney" 
mailto:c...@letsencrypt.org>> wrote:

Hi Diego,

There is a Boulder-based full implementation

Does Telefonica plan to maintain the copy of Boulder you forked into this repo 
as a stand-alone project separate from 
github.com/letsencrypt/boulder?

On Wed, Jan 16, 2019 at 6:21 PM Diego R. Lopez 
mailto:diego.r.lo...@telefonica.com>> wrote:
Hi,

There is a Boulder-based full implementation (including the delegation 
mechanisms in draft-ietf-acme-star-delegation) available in Github:

https://github.com/mami-project/lurk

(the repository is called “lurk” and not “star” because pure historical reasons)

It has been used in several demos and pilots of STAR, within Telefonica and 
elsewhere.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 24/12/2018, 21:18, "Eric Rescorla" mailto:e...@rtfm.com>> 
wrote:

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4723


After reviewing this document, I'd like to reconsider the proposed
status of this document. Based on Section 5, it doesn't appear that
there are any production implementations of this document. Are there
any existing or planned production implementations from live CAs or
clients?  If not, this seems like a better fit for Experimental.


IMPORTANT
S 3.4.
> present and set to true, the client requests the server to allow
> unauthenticated GET to the star-certificate associated with this
> Order.
>
>  If the server accepts the request, it MUST reflect the key in the
>  Order.

it seems like some security considerations are needed here to prevent
enumeration.


S 4.1.
>  of clock-related breakage reports which account for clients that are
>  more than 24 hours behind - happen to be within 6-7 days.
>
>  In order to avoid these spurious warnings about a not (yet) valid
>  server certificate, it is RECOMMENDED that site owners pre-date their
>  Web facing certificates by 5 to 7 days.  The exact number depends on

I don't understand how this works. The client is able to provide the
notbefore date, which gives a pre-date for the first certificate, but
S 2.2 just says that the re-issue is "before the previous one
expires". So suppose it is currently 2018-07-15" and I ask for a
certificate with "recurrent-start-date=2018-07-10" and "recurrent-
certificate-validity=5", I thus get back a cert with validity
"2018-07-10 -- 2018-07-20", i.e., pre-dated by 5 days. The next
certificate needs to be issued on or before "2018-07-20", but the text
doesn't say when it's notbefore has to be, so it could have validity
"2018-07-19 -- 2018-07-25". It seems like this document needs to
specify an explicit way to pre-date, but it doesn't.


COMMENTS
S 1.
>  new short-term certificate is needed - e.g., every 2-3 days.  If done
>  this way, the process would involve frequent interactions between the
>  registration function of the ACME Certification Authority (CA) and
>  the identity provider infrastructure (e.g.: DNS, web servers),
>  therefore making the issuance of short-term certificates exceedingly
>  dependent on the reliability of both.

I don't see why this is the case. Once you have authorized once, the
CA can just return that no authorizations are required.


S 3.1.1.
>  o  recurrent-certificate-validity (required, integer): the maximum
> validity period of each STAR certificate, an integer that denotes
> a number of seconds.  This is a nominal value which does not
> include any extra validity time which is due to pre-dating.  The
> client can use this value as a hint to configure its polling
> timer.

This text is confusing. The client produces the order, so how is it
using it as a hint.


S 3.1.2.
>
>  Issuing a cancellation for an order that is not in "valid" state has
>  undefined semantics.  A client MUST NOT send such a request, and a
>  server MUST return an error response with status code 400 (Bad
>  Request) and type
>  "urn:ietf:params:acme:error:recurrentCancellationInvalid".

This doesn't sound like undefined semantics. It's just illegal.



Este 

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Salz, Rich]

Richard always wants to close WG’s.  :) His views don’t necessarily reflect 
those of the AD’s or Chairs or the WG itself.  Don’t worry about it being more 
than just one opinion of an involved person. :)
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Richard Barnes]

I would add that if this is just another token type, it might not be
necessary to keep the WG open for it.  Good exercise for the secdispatch
process.

On Thu, Jan 17, 2019 at 12:49 Rifaat Shekh-Yusef 
wrote:

> Thanks Richard,
>
> The redirection is not critical part, and your explanation makes sense.
> I looked at the "authority token" documents a while ago; I will take a
> look again to see if I can align this document with that framework.
>
> Regards,
>  Rifaat
>
>
> On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes  wrote:
>
>> It seems like the core of this draft is identifier delegation.  Namely,
>> the CA recognizes the DA as an authority for a certain identifier space
>> (e.g., the first few octets of a MAC address), and the JWT delegates
>> permission to issue certificates for some identifier in that space to the
>> Client.
>>
>> Given that, it seems to me like this could fit under the rubric of the
>> "authority token" challenge.  If you were to do what this draft wants to do
>> with that framework, the Client would have two separate interactions -- an
>> OAuth interaction with the DA to get a token, then an ACME interaction with
>> the CA to issue the certificate.  The only specification needed would be to
>> specify the identifier and token type, as has been done for TNAuthList [2].
>>
>> The only thing that would then be missing with regard to this draft is
>> that the CA wouldn't provide the redirect to the DA.  Whether that makes
>> sense depends on the use case, but I suspect that in most cases it does
>> not.  The design in the draft presumes there's a single DA per identifier,
>> and that the CA keeps a mapping table from possible identifiers to DAs.
>> That seems unlikely for most identifier spaces and most CAs with reasonably
>> broad coverage.  So losing this property of the draft doesn't seem like a
>> big issue.
>>
>> So net/net, I think this draft should be restructured along the lines of
>> [2], to just define a token type and maybe an identifier type.
>>
>> --Richard
>>
>> [1] https://tools.ietf.org/html/draft-ietf-acme-authority-token
>> [2]
>> https://tools.ietf.org/wg/acme/draft-ietf-acme-authority-token-tnauthlist/
>>
>> On Wed, Jan 16, 2019 at 12:33 PM Rifaat Shekh-Yusef <
>> rifaat.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> I have just submitted new updated version to address the issues raised
>>> by Ilari and Ryan.
>>> I would appreciate any more reviews and comments.
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>> -- Forwarded message -
>>> From: 
>>> Date: Wed, Jan 16, 2019 at 3:28 PM
>>> Subject: New Version Notification for
>>> draft-yusef-acme-3rd-party-device-attestation-01.txt
>>> To: Rifaat Shekh-Yusef 
>>>
>>>
>>>
>>> A new version of I-D,
>>> draft-yusef-acme-3rd-party-device-attestation-01.txt
>>> has been successfully submitted by Rifaat Shekh-Yusef and posted to the
>>> IETF repository.
>>>
>>> Name:   draft-yusef-acme-3rd-party-device-attestation
>>> Revision:   01
>>> Title:  Third-Party Device Attestation for ACME
>>> Document date:  2019-01-16
>>> Group:  Individual Submission
>>> Pages:  9
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-yusef-acme-3rd-party-device-attestation
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-yusef-acme-3rd-party-device-attestation-01
>>>
>>> Abstract:
>>>This document defines a Third-Party Device Attestation for ACME
>>>mechanism to allow the ACME CA to delegate some of its authentication
>>>and authorization functions to a separate trusted entity, to automate
>>>the issuance of certificates to devices.
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>> The IETF Secretariat
>>>
>>> ___
>>> 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] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Rifaat Shekh-Yusef]

Thanks Richard,

The redirection is not critical part, and your explanation makes sense.
I looked at the "authority token" documents a while ago; I will take a look
again to see if I can align this document with that framework.

Regards,
 Rifaat


On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes  wrote:

> It seems like the core of this draft is identifier delegation.  Namely,
> the CA recognizes the DA as an authority for a certain identifier space
> (e.g., the first few octets of a MAC address), and the JWT delegates
> permission to issue certificates for some identifier in that space to the
> Client.
>
> Given that, it seems to me like this could fit under the rubric of the
> "authority token" challenge.  If you were to do what this draft wants to do
> with that framework, the Client would have two separate interactions -- an
> OAuth interaction with the DA to get a token, then an ACME interaction with
> the CA to issue the certificate.  The only specification needed would be to
> specify the identifier and token type, as has been done for TNAuthList [2].
>
> The only thing that would then be missing with regard to this draft is
> that the CA wouldn't provide the redirect to the DA.  Whether that makes
> sense depends on the use case, but I suspect that in most cases it does
> not.  The design in the draft presumes there's a single DA per identifier,
> and that the CA keeps a mapping table from possible identifiers to DAs.
> That seems unlikely for most identifier spaces and most CAs with reasonably
> broad coverage.  So losing this property of the draft doesn't seem like a
> big issue.
>
> So net/net, I think this draft should be restructured along the lines of
> [2], to just define a token type and maybe an identifier type.
>
> --Richard
>
> [1] https://tools.ietf.org/html/draft-ietf-acme-authority-token
> [2]
> https://tools.ietf.org/wg/acme/draft-ietf-acme-authority-token-tnauthlist/
>
> On Wed, Jan 16, 2019 at 12:33 PM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> I have just submitted new updated version to address the issues raised by
>> Ilari and Ryan.
>> I would appreciate any more reviews and comments.
>>
>> Regards,
>>  Rifaat
>>
>>
>> -- Forwarded message -
>> From: 
>> Date: Wed, Jan 16, 2019 at 3:28 PM
>> Subject: New Version Notification for
>> draft-yusef-acme-3rd-party-device-attestation-01.txt
>> To: Rifaat Shekh-Yusef 
>>
>>
>>
>> A new version of I-D, draft-yusef-acme-3rd-party-device-attestation-01.txt
>> has been successfully submitted by Rifaat Shekh-Yusef and posted to the
>> IETF repository.
>>
>> Name:   draft-yusef-acme-3rd-party-device-attestation
>> Revision:   01
>> Title:  Third-Party Device Attestation for ACME
>> Document date:  2019-01-16
>> Group:  Individual Submission
>> Pages:  9
>> URL:
>> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/
>> Htmlized:
>> https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-yusef-acme-3rd-party-device-attestation
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-yusef-acme-3rd-party-device-attestation-01
>>
>> Abstract:
>>This document defines a Third-Party Device Attestation for ACME
>>mechanism to allow the ACME CA to delegate some of its authentication
>>and authorization functions to a separate trusted entity, to automate
>>the issuance of certificates to devices.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
>> ___
>> 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] AD Review: draft-ietf-acme-star-04

[Daniel McCarney]

Hi Diego,


> There is a Boulder-based full implementation


Does Telefonica plan to maintain the copy of Boulder you forked into this
repo as a stand-alone project separate from github.com/letsencrypt/boulder?

On Wed, Jan 16, 2019 at 6:21 PM Diego R. Lopez 
wrote:

> Hi,
>
>
>
> There is a Boulder-based full implementation (including the delegation
> mechanisms in draft-ietf-acme-star-delegation) available in Github:
>
>
>
> https://github.com/mami-project/lurk
>
>
>
> (the repository is called “lurk” and not “star” because pure historical
> reasons)
>
>
>
> It has been used in several demos and pilots of STAR, within Telefonica
> and elsewhere.
>
>
>
> Be goode,
>
>
>
> --
>
> "Esta vez no fallaremos, Doctor Infierno"
>
>
>
> Dr Diego R. Lopez
>
> Telefonica I+D
>
> https://www.linkedin.com/in/dr2lopez/
>
>
>
> e-mail: diego.r.lo...@telefonica.com
>
> Tel: +34 913 129 041
>
> Mobile:  +34 682 051 091
>
> --
>
>
>
> On 24/12/2018, 21:18, "Eric Rescorla"  wrote:
>
>
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4723
>
>
> After reviewing this document, I'd like to reconsider the proposed
> status of this document. Based on Section 5, it doesn't appear that
> there are any production implementations of this document. Are there
> any existing or planned production implementations from live CAs or
> clients?  If not, this seems like a better fit for Experimental.
>
>
> IMPORTANT
> S 3.4.
> > present and set to true, the client requests the server to allow
> > unauthenticated GET to the star-certificate associated with this
> > Order.
> >
> >  If the server accepts the request, it MUST reflect the key in the
> >  Order.
>
> it seems like some security considerations are needed here to prevent
> enumeration.
>
>
> S 4.1.
> >  of clock-related breakage reports which account for clients that are
> >  more than 24 hours behind - happen to be within 6-7 days.
> >
> >  In order to avoid these spurious warnings about a not (yet) valid
> >  server certificate, it is RECOMMENDED that site owners pre-date
> their
> >  Web facing certificates by 5 to 7 days.  The exact number depends on
>
> I don't understand how this works. The client is able to provide the
> notbefore date, which gives a pre-date for the first certificate, but
> S 2.2 just says that the re-issue is "before the previous one
> expires". So suppose it is currently 2018-07-15" and I ask for a
> certificate with "recurrent-start-date=2018-07-10" and "recurrent-
> certificate-validity=5", I thus get back a cert with validity
> "2018-07-10 -- 2018-07-20", i.e., pre-dated by 5 days. The next
> certificate needs to be issued on or before "2018-07-20", but the text
> doesn't say when it's notbefore has to be, so it could have validity
> "2018-07-19 -- 2018-07-25". It seems like this document needs to
> specify an explicit way to pre-date, but it doesn't.
>
>
> COMMENTS
> S 1.
> >  new short-term certificate is needed - e.g., every 2-3 days.  If
> done
> >  this way, the process would involve frequent interactions between
> the
> >  registration function of the ACME Certification Authority (CA) and
> >  the identity provider infrastructure (e.g.: DNS, web servers),
> >  therefore making the issuance of short-term certificates exceedingly
> >  dependent on the reliability of both.
>
> I don't see why this is the case. Once you have authorized once, the
> CA can just return that no authorizations are required.
>
>
> S 3.1.1.
> >  o  recurrent-certificate-validity (required, integer): the maximum
> > validity period of each STAR certificate, an integer that denotes
> > a number of seconds.  This is a nominal value which does not
> > include any extra validity time which is due to pre-dating.  The
> > client can use this value as a hint to configure its polling
> > timer.
>
> This text is confusing. The client produces the order, so how is it
> using it as a hint.
>
>
> S 3.1.2.
> >
> >  Issuing a cancellation for an order that is not in "valid" state has
> >  undefined semantics.  A client MUST NOT send such a request, and a
> >  server MUST return an error response with status code 400 (Bad
> >  Request) and type
> >  "urn:ietf:params:acme:error:recurrentCancellationInvalid".
>
> This doesn't sound like undefined semantics. It's just illegal.
>
> --
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por