Kent Watsen wrote: > My view is that, if the IDevID has a CRL/OCSP URL listed, then the > validator SHOULD do the checking. > If the vendor didn't actually want revocation checking done, then the > vendor should've excluded such information from their IDevID certs. I agree, it should say SHOULD.
> the likelihood of the credentials being stolen/discovered are near zero, > but it is not zero, as a determined adversary with sufficient resources > can still have their way with it. Also, if some general or implementation vulnerabilities are discovered in the used crypto processors/ Tamper-resistant NVRAM, the likelihood may become significantly higher than "near zero". > vendors face a more likely scenario, of issues occurring by contract > manufacturers, whether it be accidental or intentional. I agree. As there may be more & diverse such scenarios one can also think of mapping those issues to well-defined revocation reasons (keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn, and aACompromise). This would allow for more detailed decisions during enrollment (or re-enrollment after factory reset) in the local domain. Stevie -----Original Message----- From: Anima [mailto:[email protected]] On Behalf Of Kent Watsen Sent: Thursday, March 09, 2017 8:17 PM To: Eliot Lear <[email protected]>; Anima WG <[email protected]> Subject: Re: [Anima] CRLs in iDevID manufacturer signing certs? My view is that, if the IDevID has a CRL/OCSP URL listed, then the validator SHOULD do the checking. If the vendor didn't actually want revocation checking done, then the vendor should've excluded such information from their IDevID certs. FWIW, 802.1AR takes a much neutral stance in Section 6.5.3 (Validation of DevIDs): The DevID is an X.509 credential and can be validated using the RFC 5280 defined mechanisms. IDevIDs are intended to have very long validity periods even exceeding what would normally be cryptographically acceptable. The manufacturer is not required to provide a Certificate Revocation List (CRL) although the validator may do CRL checking if the manufacturer provides CRLs. The validator may verify CRLs for LDevIDs as necessary. Kent -----ORIGINAL MESSAGE----- Thanks, Kent. Then it seems to me that we have a MAY floating around for CRL checking on the part of the registrar for BRSKI. Right? Eliot On 3/9/17 7:25 PM, Kent Watsen wrote: > Hi Elliot, > > >> What is the thinking on including CRL pointer in the manufacturer >> signing cert? This question came up in industry discussions. > 802.1AR says that the IDevID secrets must be stored confidentially and be not available outside the module. In practice, a crypto processor with tamper-resistant NVRAM is used (e.g., TPM). As such, the likelihood of the credentials being stolen/discovered are near zero, but it is not zero, as a determined adversary with sufficient resources can still have their way with it. Still, vendors will likely conclude that protecting against that level of attack isn't necessary. That said, vendors face a more likely scenario, of issues occurring by contract manufacturers, whether it be accidental or intentional. And as unlikely this scenario may seem, things happen and the vendor would be without recourse if unable to issue revocations. To this extent, setting up the infrastructure to support revocations can be compared to insurance - hopefully you never need it, but when you do, you're glad you have it. > > Kent > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
