Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OCC ambiguity and missing functionality in ASN.1 schema #65

Open
dmercer-google opened this issue Sep 13, 2023 · 2 comments
Open

OCC ambiguity and missing functionality in ASN.1 schema #65

dmercer-google opened this issue Sep 13, 2023 · 2 comments

Comments

@dmercer-google
Copy link
Collaborator

The PUT_DATA_ADMIN schema enumerates pin (1) and pinAlways (2) which makes sense. For occ you have only defined occ (4) and have omitted occAlways. If you look at the Security conditions for keys 9A and 9C in 800-73-4 Part 1 Table 4b you will see that both OCC and OCC Always are used.

I suggest you:

  • change occ (4) to occAlways (4)
  • add occ (8)

In your access mode enumeration documentation here you have a row:

Occ | The object may be accessed only after a successful Biometric On-Card Comparison in the current session.

This is not consistent with your docs on Pin and Pin Always as the former is one time and the latter is good for an entire session. I suggest that upi rename Occ to Occ Always and add a row for Occ which is one time like Pin

@makinako
Copy link
Owner

The occ parameter was put there a bit prematurely in anticpation of functionality that hasn't been implemented yet.
But it is and so we should do it correctly. We have two options:

  1. We have pin, pinAlways, occ and occAlways flags as you have described.
  2. We could also just rename pinAlways to simply always or alwaysAuth

The reason for mentioning the second option is that it seems reasonable if you have both PIN and OCC authentication for an object, you would to apply the alwaysAuth flag uniformly to both. It also means from a schema/code perspective nothing changes except the field rename.
Let me know if this sounds good or if you think there's a potential use for having two separate always flags

@dmercer-google
Copy link
Collaborator Author

2 seems to be the most elegant. 1 is better for back compat

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants