RFC - support for subjectUniqueID and issuerUniqueID

[Simon Josefsson]

Brad Hards <bradh at frogmouth.net> writes:

> On Wednesday, August 11, 2010 09:31:58 pm Simon Josefsson wrote:
>> Generally, I think we should have an API to extract arbitrary extensions
>> instead of adding new APIs for each and every strange extension.  I
>> think we already have these APIs though?
> I agree.
>
>> I don't see any extensions in your certificate though?  So I'm not sure
>> exactly what fields you are talking about.
> These fields aren't an extension. From RFC 3280 (or 5280):
>    TBSCertificate  ::=  SEQUENCE  {
>         version         [0]  EXPLICIT Version DEFAULT v1,
>         serialNumber         CertificateSerialNumber,
>         signature            AlgorithmIdentifier,
>         issuer               Name,
>         validity             Validity,
>         subject              Name,
>         subjectPublicKeyInfo SubjectPublicKeyInfo,
>         issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
>                              -- If present, version MUST be v2 or v3
>         subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
>                              -- If present, version MUST be v2 or v3
>         extensions      [3]  EXPLICIT Extensions OPTIONAL
>                              -- If present, version MUST be v3
>         }
>
>> jas at mocca:~$ dumpasn1 cert
>>   13   16:     INTEGER BD 76 DF 42 47 0A 00 8D 47 3E 74 3F A1 DC 8B BD
> This is one of them (I can't tell which, since they're the same for this 
> cert). UniqueIdentifier is a BIT STRING.

Ah, thanks.  Then I believe we should have native APIs for it, since the
fields are so tied in with the core format.

/Simon