Bonsoir,
Trying to do the ASN.1 conversion while trying to stay close to the current
SCTList definition, I got this:
SignedCertificateTimestampList ::= SEQUENCE OF SignedCertificateTimestamp
SignedCertificateTimestamp ::= SEQUENCE {
sct-version Version,
id LogID,
extensions CtExtensions,
signature-of-SignedEntry Signature }
Version ::= INTEGER { v1(0) } (0..255)
LogID ::= OCTET STRING (SIZE(32))
CtExtensions ::= OCTET STRING (SIZE(0..65535))
-- No extension is defined yet, but it should probably something like this
instead:
-- CtExtensions ::= SEQUENCE OF CtExtension
-- CtExtension ::= SEQUENCE {
-- type SomeType,
-- value SomeValue (taken from an ObjectSet)
-- }
-- That's an acceptable way to define a signature, it's a BIT STRING in
X.509, and an OCTET STRING in CMS
Signature ::= OCTET STRING (SIZE(0..65535))
But what is really signed is a SignedEntry.
The SignedEntry could also be redefined in ASN.1, but then we have a
different signature. Bad.
An ASN.1 defined SignedEntry would be something like this:
SignedEntry ::= SEQUENCE {
sct-version Version,
signature-type SignatureType, -- MUST be certificate-timestamp?
timestamp Uint64,
logentry LogEntry }
SignatureType ::= INTEGER {
certificate-timestamp(0),
tree-hash(1) } (0..255)
Uint64 ::= INTEGER (0..18446744073709551616)
LogEntry ::= CHOICE {
x509entry [0] ASN1Cert,
precertentry [1] PreCert }
PreCert ::= SEQUENCE {
issuer-key-hash OCTET STRING (SIZE(32)),
tbs-certificate TBSCertificate }
-- TBSCertificate is defined in RFC5280
ASN1Cert ::= Certificate
If we give up here and consider SignedEntry to be an OCTET STRING, then the
signature doesn't apply to the SignedEntry structure itself, but to its
content (tag and length excluded). Not really PKIX way.
I can't find a clean way to solve this.
2015-03-13 22:19 GMT+01:00 Rob Stradling <[email protected]>:
>
> On 13/03/15 21:15, Rob Stradling wrote:
>
>> On 13/03/15 21:05, Stephen Farrell wrote:
>>
>>> On 13/03/15 20:58, Rob Stradling wrote:
>>>
>>>> On 13/03/15 20:25, Stephen Farrell wrote:
>>>> <snip>
>>>>
>>>>> And if we interpret 5280 strictly and conclude that is still a
>>>>> good plan then the question would be what to do about the SCT
>>>>> encoding, which could be to do something hacky like prepending
>>>>> another OCTET STRING tag and a length I suppose,
>>>>>
>>>>
>>>> Stephen, RFC6962 does precisely that, and the current 6962-bis text aims
>>>> to do the same.
>>>>
>>>
>>> Really?
>>>
>>
>> Really. That's what all the current implementations of RFC6962 are doing.
>>
>
> It probably doesn't help that RFC6962 has two definitions of "
> SignedCertificateTimestampList", one using ASN.1 and one using TLS
> encoding rules.
>
> SignedCertificateTimestampList ::= OCTET STRING
>
> struct {
> SerializedSCT sct_list <1..2^16-1>;
> } SignedCertificateTimestampList;
>
> This issue is addressed in 6962-bis -07.
>
> I though the extnValue was just the SignedCertificateTimestampList
>>> and did not contain yet another OCTET STRING tag? That how I read
>>> 6962 anyway.
>>>
>>
>> Some other folks read it that way too, apparently.
>>
>> Hence http://trac.tools.ietf.org/wg/trans/trac/ticket/14
>>
>> S.
>>>
>>>
>>>> Adding yet another OCTET STRING would turn it into an OCTET STRING
>>>> inside an OCTET STRING inside an OCTET STRING!
>>>>
>>>> I'd be surprised if Russ or Steve Kent would consider that to be any
>>>> better than the current plan (an OCTET STRING inside an OCTET STRING).
>>>>
>>>
>>
>
--
Erwann.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
