On 31/03/14 10:32, Rob Stradling wrote:
Hi Rick. Dave's analysis is correct. 6962, interpreted in the light of
X.509/5280, is unambiguous. That said, I think we could make life
easier for implementers by improving the text in RFC6962-bis.
We should certainly add at least one example of an encoded SCTList
extension.
http://trac.tools.ietf.org/wg/trans/trac/ticket/14
On 28/03/14 18:00, Rick Andrews wrote:
Thanks, Dave, I’ll forward this on. But are you saying that the
descriptions in 6962 are precise enough? Would you have any objections
to defining structures in 6962 using the same syntax as 5280?
-Rick
*From:*David A. Cooper [mailto:[email protected]]
*Sent:* Friday, March 28, 2014 10:55 AM
*To:* Rick Andrews
*Cc:* [email protected]
*Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
Rick,
I haven't read RFC 6962 in detail, but the ASN.1 experts you spoke with
may not be familiar with the definition of Extension in certificates.
X.509 defines it as:
* Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
(CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
ENCODED BY der)}
der OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1) ber-derived(2)
distinguished-encoding(1)}
*
In RFC 5280 it is:
* Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}*
It is my understanding that the two definitions are based on different
versions of ASN.1, but are considered to be equivalent. The important
point is that both indicate that the extension value must contain the
DER encoding of some ASN.1 value. So, the only way to interpret the RFC
6962 text in a manner that is consistent with X.509 is that the
extnValue contains the tag for OCTET STRING followed by a length then a
second OCTET STRING tag and a second length and then the (non-ASN.1)
encoded SignedCertificateTimestampList structure. Given that the
SignedCertificateTimestampList structure is not ASN.1, and so it cannot
be DER encoded, this seems the only reasonable way to include it in a
certificate.
This is similar to the subjectKeyIdentifier extension. The
subjectKeyIdentifier just contains a string of bits, such as the SHA-1
hash of the subject public key. It is defined in RFC 5280 as follows:
* KeyIdentifier ::= OCTET STRING
-- subject key identifier OID and syntax
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier*
and here is an example of an encoded subjectKeyIdentifier extension:
*SEQUENCE {**
SEQUENCE {
OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
OCTET STRING, encapsulates {
OCTET STRING
08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A
20 84 2C 32
}
}*
RFC 5912 shows the extensions in the newer ASN.1 syntax.
Dave
On 03/28/2014 01:31 PM, Rick Andrews wrote:
In addition, our ASN.1 experts have asked for the syntax to be
described in “ASN.1-like” syntax, as is used in RFCs 3280 and 5280.
For example, 3280/5280 defines an Extension like this:
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
so the extnValue is defined as an OCTET STRING, yet 6962 says
“…encoding the SignedCertificateTimestampList structure as an ASN.1
OCTET STRING and inserting the resulting data in the TBSCertificate
as an X.509v3 certificate extension…”. The ASN.1 folks say it’s not
clear if that means that the Extension contains the OCTET STRING
data type (for extnValue) and length followed by another OCTET
STRING data type identifier and length of the SCT. Or is the second
OCTET STRING identifier redundant?
Those updating existing cert generation code will probably be
dealing with ASN.1 compilers, so a precise definition of structures
in ASN.1-like syntax will go a long way. In addition, defining OIDs
as arc plus extension (like this: id-kp-serverAuth OBJECT
IDENTIFIER ::= { id-kp 1 }) would help.
-Rick
*From:*Trans [mailto:[email protected]] *On Behalf Of *Eran
Messeri
*Sent:* Friday, March 14, 2014 3:01 AM
*To:* Phillip Hallam-Baker
*Cc:* Rob Stradling; [email protected] <mailto:[email protected]>
*Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
I strongly support clarifying the description of the file format.
When I started implementing aspects of RFC6962 (with no background
in TLS encoding or ASN.1) it was very unclear.
From other posts
<https://groups.google.com/forum/#%21topic/certificate-transparency/T9CDwnsercQ>
on the list it seems this was unclear to others as well.
On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker
<[email protected] <mailto:[email protected]>> wrote:
On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling
<[email protected] <mailto:[email protected]>> wrote:
(Inspired by RFC5280 Appendix C)
Would it help to include one or more example SCTs in the text?
I think we definitely need that for Proposed. But right now I am
trying to see how complete the description is.
--
Website: http://hallambaker.com/
_______________________________________________
Trans mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
