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

[Richard Barnes]

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] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Rifaat Shekh-Yusef]

Thanks Ilari,

Section 2.4 is a informative section that meant to provide a high level
view of the full flow.

Remember that the assumption is that the Client already has an account with
ACME and already proved it controls customer.com domain.

The first request in this flow will be the same as defined in section 7.4
in the acme draft:
https://tools.ietf.org/html/draft-ietf-acme-acme-18#section-7.4
The only difference is that the url will contain the new order with the
vendor.com to indicate that it is requesting a certificate for a device
controlled by this Device Authority.

Hope this helps.
I will try to expand on this in the next version of the document.

Regards,
 Rifaat






On Wed, Jan 16, 2019 at 4:15 PM Ilari Liusvaara 
wrote:

> On Wed, Jan 16, 2019 at 03:32:57PM -0500, 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.
> >
> > -- Forwarded message -
> > Name:   draft-yusef-acme-3rd-party-device-attestation
> > Revision:   01
> >
> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt
>
> Other comments:
>
> - How the ACME server can look up the client account with kid field
>   (which normally contains the client account identifier) now contains
>   the client domain?
> - URL field in first request seems to be also overloaded. Considering
>   that this field actually has security significance (prevent misrouting
>   to different resource), this seems questionable.
> - Constructing URL poiting to the client without knowledge of used paths
>   is very questionable.
> - It seems to me that this should be handled by defining a new validation
>   method for the mac identifiers, without touching rest of ACME. Then
>   the CA would send those back for mac identifiers (together with the
>   needed references) and then take the JWT as reply.
>
>
> -Ilari
>
___
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,

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 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 esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please 

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

[Ilari Liusvaara]

On Wed, Jan 16, 2019 at 03:32:57PM -0500, 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.
> 
> -- Forwarded message -
> Name:   draft-yusef-acme-3rd-party-device-attestation
> Revision:   01
> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt

Other comments:

- How the ACME server can look up the client account with kid field
  (which normally contains the client account identifier) now contains
  the client domain?
- URL field in first request seems to be also overloaded. Considering
  that this field actually has security significance (prevent misrouting
  to different resource), this seems questionable.
- Constructing URL poiting to the client without knowledge of used paths
  is very questionable. 
- It seems to me that this should be handled by defining a new validation
  method for the mac identifiers, without touching rest of ACME. Then
  the CA would send those back for mac identifiers (together with the
  needed references) and then take the JWT as reply. 


-Ilari

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

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

[Rifaat Shekh-Yusef]

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