[Cscwg-public] FW: RSA3161 Reqs

Thu Mar 28 09:32:53 MST 2019

Per our discussion today

From: codesigning-bounces at cabforum.org <codesigning-bounces at cabforum.org> On
Behalf Of Jeremy Rowley
Sent: Tuesday, February 16, 2016 2:13 PM
To: codesigning at cabforum.org
Subject: [cabfc_s] RSA3161 Reqs

Looking at this more, I think we should separate the requirements into two
parts. Operational requirements and technical requirements. The operational
requirements should go into the requirements doc. The technical requirements
can be incorporated by reference saying that the CA must accept requests and
provide responses in accordance with RFC 3161. 

Here are all the requirements from 3161:

OPERATIONAL REQUIREMENTS:

The TSA is REQUIRED:

1. to use a trustworthy source of time.

2. to include a trustworthy time value for each time-stamp token.

3. to include a unique integer for each newly generated time-stamp

token.

4. to produce a time-stamp token upon receiving a valid request

from the requester, when it is possible.

5. to include within each time-stamp token an identifier to

uniquely indicate the security policy under which the token was

created.

6. to only time-stamp a hash representation of the datum, i.e., a

data imprint associated with a one-way collision resistant

hash-function uniquely identified by an OID.

7. to examine the OID of the one-way collision resistant hash-

function and to verify that the hash value length is consistent

with the hash algorithm.

8. not to examine the imprint being time-stamped in any way (other

than to check its length, as specified in the previous bullet).

9. not to include any identification of the requesting entity in

the time-stamp tokens.

10. to sign each time-stamp token using a key generated exclusively

for this purpose and have this property of the key indicated on

the corresponding certificate.

11. to include additional information in the time-stamp token, if

asked by the requester using the extensions field, only for the

extensions that are supported by the TSA. If this is not

possible, the TSA SHALL respond with an error message.

The TSA MUST sign each time-stamp message with a key reserved

specifically for that purpose. A TSA MAY have distinct private keys,

e.g., to accommodate different policies, different algorithms,

different private key sizes or to increase the performance. 

TECHNICAL REQUIREMENTS:

The corresponding certificate MUST contain only one instance of the

extended key usage field extension as defined in [RFC2459] Section

4.2.1.13 with KeyPurposeID having value:

id-kp-timeStamping. This extension MUST be critical.

The following object identifier identifies the KeyPurposeID having

value id-kp-timeStamping.

id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)

identified-organization(3) dod(6)

internet(1) security(5) mechanisms(5) pkix(7)

kp (3) timestamping (8)}

A time-stamping request is as follows:

TimeStampReq ::= SEQUENCE {

version INTEGER { v1(1) },

messageImprint MessageImprint,

--a hash algorithm OID and the hash value of the data to be

reqPolicy TSAPolicyId OPTIONAL,

nonce INTEGER OPTIONAL,

certReq BOOLEAN DEFAULT FALSE,

extensions [0] IMPLICIT Extensions OPTIONAL }

MessageImprint ::= SEQUENCE {

hashAlgorithm AlgorithmIdentifier,

hashedMessage OCTET STRING }

If the certReq field is present and set to true, the TSA's public key

certificate that is referenced by the ESSCertID identifier inside a

SigningCertificate attribute in the response MUST be provided by the

TSA in the certificates field from the SignedData structure in that

response. That field may also contain other certificates.

If the certReq field is missing or if the certReq field is present

and set to false then the certificates field from the SignedData

structure MUST not be present in the response.

A time-stamping response is as follows:

TimeStampResp ::= SEQUENCE {

status PKIStatusInfo,

timeStampToken TimeStampToken OPTIONAL }

PKIStatusInfo ::= SEQUENCE {

status PKIStatus,

statusString PKIFreeText OPTIONAL,

failInfo PKIFailureInfo OPTIONAL }

When the status contains the value zero or one, a TimeStampToken MUST

be present. When status contains a value other than zero or one, a

TimeStampToken MUST NOT be present. One of the following values MUST

be contained in status:

PKIStatus ::= INTEGER {

granted (0),

-- when the PKIStatus contains the value zero a TimeStampToken, as

requested, is present.

grantedWithMods (1),

-- when the PKIStatus contains the value one a TimeStampToken,

with modifications, is present.

rejection (2),

waiting (3),

revocationWarning (4),

-- this message contains a warning that a revocation is

-- imminent

revocationNotification (5)

-- notification that a revocation has occurred }

Compliant clients MUST generate an error if values it does not understand
are

present.

When the TimeStampToken is not present, the failInfo indicates the

reason why the time-stamp request was rejected and may be one of the

following values.

PKIFailureInfo ::= BIT STRING {

badAlg (0),

-- unrecognized or unsupported Algorithm Identifier

badRequest (2),

-- transaction not permitted or supported

badDataFormat (5),

-- the data submitted has the wrong format

timeNotAvailable (14),

-- the TSA's time source is not available

unacceptedPolicy (15),

-- the requested TSA policy is not supported by the TSA

unacceptedExtension (16),

-- the requested extension is not supported by the TSA

addInfoNotAvailable (17)

-- the additional information requested could not be understood

-- or is not available

systemFailure (25)

-- the request cannot be handled due to system failure }

These are the only values of PKIFailureInfo that SHALL be supported.

Compliant servers SHOULD NOT produce any other values. Compliant

clients MUST generate an error if values it does not understand are

present.

The statusString field of PKIStatusInfo MAY be used to include reason

text such as "messageImprint field is not correctly formatted".

A TimeStampToken is as follows. It is defined as a ContentInfo

([CMS]) and SHALL encapsulate a signed data content type.

TimeStampToken ::= ContentInfo

-- contentType is id-signedData ([CMS])

-- content is SignedData ([CMS])

The fields of type EncapsulatedContentInfo of the SignedData

construct have the following meanings:

eContentType is an object identifier that uniquely specifies the

content type. For a time-stamp token it is defined as:

id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

eContent is the content itself, carried as an octet string.

The eContent SHALL be the DER-encoded value of TSTInfo.

The time-stamp token MUST NOT contain any signatures other than the

signature of the TSA. The certificate identifier (ESSCertID) of the

TSA certificate MUST be included as a signerInfo attribute inside a

SigningCertificate attribute.

TSTInfo ::= SEQUENCE {

version INTEGER { v1(1) },

policy TSAPolicyId,

messageImprint MessageImprint,

-- MUST have the same value as the similar field in

-- TimeStampReq

serialNumber INTEGER,

-- Time-Stamping users MUST be ready to accommodate integers

-- up to 160 bits.

genTime GeneralizedTime,

accuracy Accuracy OPTIONAL,

ordering BOOLEAN DEFAULT FALSE,

nonce INTEGER OPTIONAL,

-- MUST be present if the similar field was present

-- in TimeStampReq. In that case it MUST have the same value.

tsa [0] GeneralName OPTIONAL,

extensions [1] IMPLICIT Extensions OPTIONAL }

The version field (currently v1) describes the version of the time-

stamp token.

Conforming time-stamping servers MUST be able to provide version 1

time-stamp tokens.

Among the optional fields, only the nonce field MUST be supported.

Conforming time-stamping requesters MUST be able to recognize version

1 time-stamp tokens with all the optional fields present, but are not

mandated to understand the semantics of any extension, if present.

The policy field MUST indicate the TSA's policy under which the

response was produced. If a similar field was present in the

TimeStampReq, then it MUST have the same value, otherwise an error

(unacceptedPolicy) MUST be returned. This policy MAY include the

following types of information (although this list is certainly not

exhaustive):

* The conditions under which the time-stamp token may be used.

* The availability of a time-stamp token log, to allow later

verification that a time-stamp token is authentic.

The messageImprint MUST have the same value as the similar field in

TimeStampReq, provided that the size of the hash value matches the

expected size of the hash algorithm identified in hashAlgorithm.

The serialNumber field is an integer assigned by the TSA to each

TimeStampToken. It MUST be unique for each TimeStampToken issued by

a given TSA (i.e., the TSA name and serial number identify a unique

TimeStampToken). It should be noticed that the property MUST be

preserved even after a possible interruption (e.g., crash) of the

service.

genTime is the time at which the time-stamp token has been created by

the TSA. It is expressed as UTC time (Coordinated Universal Time) to

reduce confusion with the local time zone use. UTC is a time scale,

based on the second (SI), as defined and recommended by the CCIR, and

maintained by the Bureau International des Poids et Mesures (BIPM). A

synonym is "Zulu" time which is used by the civil aviation and

represented by the letter "Z" (phonetically "Zulu").

The ASN.1 GeneralizedTime syntax can include fraction-of-second

details. Such syntax, without the restrictions from [RFC 2459]

Section 4.1.2.5.2, where GeneralizedTime is limited to represent the

time with a granularity of one second, may be used here.

GeneralizedTime values MUST include seconds. However, when there is

no need to have a precision better than the second, then

GeneralizedTime with a precision limited to one second SHOULD be used

(as in [RFC 2459]).

The syntax is: YYYYMMDDhhmmss[.s...]Z

Example: 19990609001326.34352Z

X.690 | ISO/IEC 8825-1 provides the following restrictions for a

DER-encoding. 

The encoding MUST terminate with a "Z" (which means "Zulu" time). The

decimal point element, if present, MUST be the point option ".". The

fractional-seconds elements, if present, MUST omit all trailing 0's;

if the elements correspond to 0, they MUST be wholly omitted, and the

decimal point element also MUST be omitted.

Midnight (GMT) shall be represented in the form: "YYYYMMDD000000Z"

where "YYYYMMDD" represents the day following the midnight in

question.

Here are a few examples of valid representations:

"19920521000000Z"

"19920622123421Z"

"19920722132100.3Z"

accuracy represents the time deviation around the UTC time contained

in GeneralizedTime.

Accuracy ::= SEQUENCE {

seconds INTEGER OPTIONAL,

millis [0] INTEGER (1..999) OPTIONAL,

micros [1] INTEGER (1..999) OPTIONAL }

If either seconds, millis or micros is missing, then a value of zero

MUST be taken for the missing field.

By adding the accuracy value to the GeneralizedTime, an upper limit

of the time at which the time-stamp token has been created by the TSA

can be obtained. In the same way, by subtracting the accuracy to the

GeneralizedTime, a lower limit of the time at which the time-stamp

token has been created by the TSA can be obtained.

accuracy can be decomposed in seconds, milliseconds (between 1-999)

and microseconds (1-999), all expressed as integer.

When the accuracy optional field is not present, then the accuracy

may be available through other means, e.g., the TSAPolicyId.

If the ordering field is missing, or if the ordering field is present

and set to false, then the genTime field only indicates the time at

which the time-stamp token has been created by the TSA. In such a

case, the ordering of time-stamp tokens issued by the same TSA or

different TSAs is only possible when the difference between the

genTime of the first time-stamp token and the genTime of the second

time-stamp token is greater than the sum of the accuracies of the

genTime for each time-stamp token.

If the ordering field is present and set to true, every time-stamp

token from the same TSA can always be ordered based on the genTime

field, regardless of the genTime accuracy.

The nonce field MUST be present if it was present in the

TimeStampReq. In such a case it MUST equal the value provided in the

TimeStampReq structure.

The purpose of the tsa field is to give a hint in identifying the

name of the TSA. If present, it MUST correspond to one of the

subject names included in the certificate that is to be used to

verify the token. However, the actual identification of the entity

that signed the response will always occur through the use of the

certificate identifier (ESSCertID Attribute) inside a

SigningCertificate attribute which is part of the signerInfo (See

Section 5 of [ESS]).

extensions is a generic way to add additional information in the

future. Extensions is defined in [RFC 2459].

Particular extension field types may be specified in standards or may

be defined and registered by any organization or community.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/cscwg-public/attachments/20190328/d6d6f6fb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/cscwg-public/attachments/20190328/d6d6f6fb/attachment-0001.p7s>