Currently x509.ParseCertificate/x509.CreateCertificate supports automatically parsing out the policyIdentifiers from a certificatePolicies extension (into Certificate.PolicyIdentifiers) but ignores the optional policyQualifiers sequence. This field is often used to transmit a CPS pointer URL (for root and intermediate certificates) and a user notice (for end entity certificates).
It'd be great if we could get automatic parsing for this full structure, instead of just the OIDs, so that we don't have to implement extra post-parsing parsing of extensions to get the full value and/or manually constructing the extension and sticking it in ExtraExtensions for creation.
RFC 5280 only defines two possible qualifier types, id-qt-cps and id-qt-unotice, the vales of both of which can be safely mapped to and from a string, so I don't think we need anything fancier than that. I think the simplest implementation would be to add a new field to Certificate with the following structure:
CertificatePolicies []struct{
Id asn1.ObjectIdentifier
Qualifiers []struct{
Id asn1.ObjectIdentifier
Qualifier string
}
}
This would then be populated during parsing, and marshaled into an extension during creation. There is a question of what do to with the existing PoliciyIdentifiers field, i.e. if both are populated how should a call to CreateCertificate behave. I think for now it'd make sense to document that only one of them is allowed, and populating both would result in an error.
cc @FiloSottile
Currently
x509.ParseCertificate/x509.CreateCertificatesupports automatically parsing out thepolicyIdentifiers from acertificatePoliciesextension (intoCertificate.PolicyIdentifiers) but ignores the optionalpolicyQualifierssequence. This field is often used to transmit a CPS pointer URL (for root and intermediate certificates) and a user notice (for end entity certificates).It'd be great if we could get automatic parsing for this full structure, instead of just the OIDs, so that we don't have to implement extra post-parsing parsing of extensions to get the full value and/or manually constructing the extension and sticking it in
ExtraExtensionsfor creation.RFC 5280 only defines two possible qualifier types,
id-qt-cpsandid-qt-unotice, the vales of both of which can be safely mapped to and from a string, so I don't think we need anything fancier than that. I think the simplest implementation would be to add a new field toCertificatewith the following structure:This would then be populated during parsing, and marshaled into an extension during creation. There is a question of what do to with the existing
PoliciyIdentifiersfield, i.e. if both are populated how should a call toCreateCertificatebehave. I think for now it'd make sense to document that only one of them is allowed, and populating both would result in an error.cc @FiloSottile