Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest

[Sebastian Nielsen <[e-mail]>]

I think a even better idea is to actually support passports for real.

Passports and ID-cards (with an MRZ), and some driver licenses with an MRZ
today contain a NFC chip, so a ACME server could provide this as a
validation method for getting a fully validated certificate.

 

The passports can then be validated electronically using the country signer
key, and then a fully validated certificate can be issued.

 

 

On the topic of validating in the “passport model” however, is that if the
attestation from the verifier is fraudulent, there is no possibility for the
verifier to revoke it.

This serves less of a importance if the ownership of physical device is
being attested, whose contains no identity information.

 

But if it’s a device or attestation linked to a person or organization,
there must be a way to revoke said credential, for example if it becomes
lost. Which means you have to implement the “background check” topology
regardless, and in some way, check the attestation with the verifier to
ensure it hasn’t been blocked.

 

 

There is a third model however, which mixes background check and passport
model.

That is, you have a long-lived attestation from a verifier. You then get a
short-lived attestation that the long lived attestation is still valid
(think OCSP protocol here)

You then send both attestations to the RP (OCSP Stapling).

This only serves a advantage if you need to verify yourself against many RPs
in a short timeframe, and you want to ease up the load on the verifier.

 

In a certificate issuance situation, this will never become a problem, since
a ACME server will only contact a verifier a few times per 30/60/90 days.

Thus the “background check” model can always be used.

 

Från: [e-mail] <[e-mail]> För Thomas Fossati
Skickat: den 24 november 2022 13:35
Till: Deb Cooley <[e-mail]>; IETF ACME <[e-mail]>
Kopia: [e-mail]
Ämne: Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest

 

I have read the draft and I think it brings a very valuable feature into the
ACME ecosystem.  It’s also a perfect fit in at least two of our projects,
and I’d be happy to integrate it in our protocol flows.

 

The only concern I have with the current proposal is its reliance on
WebAuthn’s as the sole encap format.  The trouble is it only allows
“background check”-style topologies [1], whilst we’d like to be able to
support “passport” [2] as well.   Therefore, I’d like to have WebAuthn as
one of the supported formats, rather than the only supported format.  (For a
more generic encapsulation of attestation-related payloads you may want to
take a look at [3].)

 

Cheers, thanks

t

 

[1]
https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#section
-5.2

[2]
https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#section
-5.1

[3] https://datatracker.ietf.org/doc/draft-ftbs-rats-msg-wrap/

 

On 15/11/2022, 18:03, "Acme" <[e-mail]
<mailto:[e-mail]> > wrote:

 


This will be a three week call for adoption ending on 6 Dec. (because of
holidays in the US).   Please speak up either for or against adopting this
draft.  

Thanks, 
Deb and Yoav.

	

 

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.