Mike Ounsworth <[email protected]> wrote: MO> Good point about requiring some kind of coordination between ACME and MO> RATS layers. One example, is that I've been pushing that this draft MO> include some sort of hint whereby the ACME Server can specify what MO> property it needs attested -- ex.: some cert profiles might require MO> proof that the private key is in a FIPS 140-3 module,
-> lamps-csr-attestation
MO> while others
MO> might require attestation of the serial number of the device,
-> acme-device-attest
MO> while
MO> others might require proof that you are running the corporate
MO> anti-virus and which Windows domain user is currently logged-in. To
-> This document.
At this point, the client needs to know all of these criteria, as it has to
propose the right set of (ACME) identifiers, or do the right CSR-dance.
I think that it's reasonable for some other ACME document to offer a new
end-point for a machine readable "CPS" equivalent that could tell the client
the criteria. Can we agree that this is orthogonal?
MO> Type 1: the device has a hard-coded Verifier to contact -- say, it's
MO> manufacturer -- in this type, the AR is sorta filling the role of
MO> Evidence; ie from the RA/CA's perspective, it doesn't really matter
MO> whether it is presented Evidence signed by an onboard key on the
MO> device, or an AR signed by a Verifier run by the device's
MO> manufacturer; either way the relevant Trust Anchor is probably the
MO> same; the device's manufacturer.
Yes, that's true.
But, the AR is ideally vendor-independent "evidence", and requires no
vendor-specific Endorsements or Reference Values. That's the key layer of
indirection that 9334 introduced.
MO> Type 2: the RA/CA redirects the device to a Verifier chosen by the
MO> RA/CA to obtain a passport and come back. This is necessarily more
MO> complex in both wire negotiation, trust anchor management, etc.
This does not seem likely to work to me for the reasons you suggest.
MO> I suspect for for cert enrollment, where we need to consider Passport
MO> Model, it's sufficient to only accommodate Type 1 -- ie the device
MO> shows up with Evidence and/or Endorsements and/or ARs and the RA/CA
MO> either accepts them or it doesn't, but you don't need any in-protocol
MO> negotiation of which Verifier the device is supposed to contact.
Good.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
