Re: [TLS] TLS grammar checker?

[Carl Wallace <[e-mail]>]

See RFC5911 and RFC5912.  Those provide a nice collection. 

On Jun 21, 2013, at 5:33 PM, [e-mail] (Martin Rex) wrote:

> the most appropriate guidance is probably in X.208-1988 Section 32,
> but the source of the original confusion is from where the information
> originally comes from, that OCSP conveys in these fields.
> 
> When the mentioned OCSP elements originate from X.509 and PKIX CRLs,
> then from an element that is defined as (e.g. rfc5280 page 17):
> 
>   Time ::= CHOICE {
>        utcTime        UTCTime,
>        generalTime    GeneralizedTime }
> 
> and the CRL definition (rfc5280, page 56):
> 
>   CertificateList  ::=  SEQUENCE  {
>        tbsCertList          TBSCertList,
>        signatureAlgorithm   AlgorithmIdentifier,
>        signatureValue       BIT STRING  }
> 
>   TBSCertList  ::=  SEQUENCE  {
>        version                 Version OPTIONAL,
>                                     -- if present, MUST be v2
>        signature               AlgorithmIdentifier,
>        issuer                  Name,
>        thisUpdate              Time,
>        nextUpdate              Time OPTIONAL,
>        revokedCertificates     SEQUENCE OF SEQUENCE  {
>             userCertificate         CertificateSerialNumber,
>             revocationDate          Time,
>             crlEntryExtensions      Extensions OPTIONAL
>                                      -- if present, version MUST be v2
>                                  }  OPTIONAL,
>        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
>                                      -- if present, version MUST be v2
>                                  }
> 
> But the real problem really isn't about whether you can find something
> intelligible hidden somewhere in some X.something document, but how
> clear will this be to an average implementor.  And on this particular
> account, ASN.1 is a real nightmare.
> 
> 
> -Martin
> 
> 
> Martin Rex wrote:
>> Kemp, David P. wrote:
>>> Of all the possible criticisms of ASN.1, this doesn't seem to be
>>> among them.  X.680 is unambiguous - the year MUST be 4 digits:
>> 
>> Your answer is way off the target.
>> 
>> I didn't ask about what to send out, but what to accept(!) and why.
>> 
>> rfc2560 OSCP is based on X.690-1994:
>>   http://tools.ietf.org/html/rfc2560#section-6
>> 
>>   [X.690]   ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,
>>             Information Technology - ASN.1 encoding rules:
>>             Specification of Basic Encoding Rules (BER), Canonical
>>             Encoding Rules (CER) and Distinguished Encoding Rules
>>             (DER).
>> 
>> If you search X.680 from 1994 for GeneralizedTime, it only says that it
>> is a reserved keyword (therefore useless for the question at hand).
>> 
>> In order to figure out what to **ACCEPT**, you have to refer to the
>> original specifcation exclusively.
>> 
>> 
>> Your quote seems to be from X.680 2008.
>> 
>> -Martin
>> 
>>> 
>>>  46.3 The type is defined, using ASN.1, as follows:
>>>      GeneralizedTime ::= [UNIVERSAL 24] IMPLICIT VisibleString
>>>      with the values of the VisibleString restricted to strings
>>>      of characters which are either:
>>>          a) a specification of a calendar date followed by a local
>>>             time, consisting of:
>>>             1) a string representing the calendar date, as specified
>>>                in ISO 8601, 4.1.2.2 - Basic format); followed by:
>>> 
>>>                 NOTE 1 - This specifies a four-digit representation
>>>                 of the year, a two-digit representation of the month
>>>                 and a two-digit representation of the day, without
>>>                 use of separators.
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> 
>>> To illustrate one of my many problems with ASN.1 complexity and lack
>>> of clarity, I was recently wondering on OCSP, whether it is permissible
>>> or not _on_receipt_ when the "RevodedInfo->revocationTime" element
>>> 
>>>   http://tools.ietf.org/html/rfc2560#page-9
>>> 
>>> or the CRL Extension "CRL References" "CrlID->crlTime" element
>>> 
>>>   http://tools.ietf.org/html/rfc2560#section-4.4.2
>>> 
>>> contains a date&time with only 2-year, where exactly in ASN.1 it is
>>> described how the receiver ought to be implemented, and whether
>>> support for 2-digit years in GeneralizedTime is a "MAY", "SHOULD NOT"
>>> or "MUST NOT".
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls