Assigned
Status Update
Comments
ba...@google.com <ba...@google.com>
ka...@google.com <ka...@google.com> #2
I highly support this, this way every current FormGroup
subclass can define only the functions it needs (Everything besides Address
can get rid of the AutofillType
API and of the app_locale
parameters, many classes could also get rid of the VerificationStatus
API, etc.)
AutofillProfile
could then implement a GetDataForType(FieldType) -> absl::variant<Address, NameInfo, ...>
and provide the current API with visit
calls instead of polymorphism.
Description
Feature Request
We want to use the Certificate Authority Service to issue client certificates. These client certificates should be valid for exactly the time specified. This means the validity of the certificate ("notBefore" and "notAfter" date) should be exactly the values provided.
Current Implementation
Currently, there is only the option to provide a validity in the ISO8601 duration format. But this just defines a duration, e.g., P30D means the certificate should be valid for 30 days. The Certificate Authority Service sets the exact "notBefore" and "notAfter" dates of the certificates. This is described in the SDK documentation :
The biggest drawbacks of only specifying the period is that (1) we do not have complete control the validity of the certificates (which may lead to unwanted "notBefore" and/or "notAfter" dates of the certificates) and (2) we cannot backdate the certificate "notBefore" date in the past (we use this extensively to ensure that time differences do not affect the start validity of the certificate and it can be used right away).
I have seen a similar feature request Backdate the Certificate 'ValidFrom' / 'notBefore' Timestamp .
Solution Proposal
What we imagine is a feature as provided for AWS Private Certificate Authorities, where we can directly set the "notBefore" and "notAfter" date of the certificates. This is described in the API reference
and the validity API parameter specification :
An example of a request including both "ValidityNotBefore" and "Validity" could be:
We use this feature to set both Validity and ValidityNotBefore as "ABSOLUTE" unix timestamps. This allows us to have complete control of the certificate's "notBefore" and "notAfter" date and does not leave room for interpretation of the Certificate Authority Service.